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1 

Reformat the functional requirements to enumerated sections 



Exh. 2 - Page 1 



Subject: 

(brief description of change) 



1 . Job Entry-EWO: Provide the functionality of move work 

from a contract(s) to another contract(s) as master contracts 
expire. 

2. Job Entry-EWO: Add batch process to accommodate item 1. 

3. Job Entry-EWO: Provide the functionality to configure and 
assign a job to a new master contract not yet in effect 

4. Job Entry-EWO: Revise the Contract Bid form to facilitate 
the moving of individual substeps. 

5. Job Entry-EWO: Change the configuration process so it 
knows when to include open and closed substeps in 
configuration. 

6. Job Entry-EWO: Remove the functionality in configuration 
that uses the contract "type" logic. 

7. Configuration Editor: Remove the Contract Type field on the 
Resource Group/Work Type form. 

8. Management Reports: Remove Contract Type column from 
the Resource Configuration Report. 



Introduction: 

(description of what system Currently, the system has no method of transferring work 
currently does, what needs authorizations from the old contract to the new when a master 
to be changed and why) contract is expiring. These changes will allow the field users to 

move work from one contract to another. It will also allow work, 
which is being encoded, to be configured and assigned to a new 
master contract not yet in effect. 
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Solution: 



(describe what the system 
will or should do and any 
general constraints or 
conditions that limit the 



1 . Job Entry-EWO: Create a new form to identify entire jobs to 
be moved from the old contract number(s) to the new 
contract(s). 



solution) 



2. Job Entry-EWO: Create a new process to facilitate the moving 
of entire jobs from the old contract(s) to the new contract(s). 

3. Job Entry-EWO: Provide a new field on the Encode a New 
Job form and the Job form to designate a Contract Date which 
will be used to determine what contract is in effect at a 
particular date in time. This will provide the user the ability 
to encode work to a contract, which is not yet in effect. 
Change the configuration processes to use contract(s) which 
are in effect for that wire center on a specified Contract Date 
rather than the current date. 

4. Job Entry-EWO: Revise the Contract Bid from to facilitate the 
moving of individual substeps between contracts. 

5. Job Entry-EWO: Change the configuration process so that it 
knows when to include both open and closed steps when 
calculating CWIs. 

6. Job Entry-EWO: Remove the functionality in configuration 
that uses the contract "type" logic. 

7. Configuration Editor: Remove the Contract Type field in 

configuration editor on the Resource Group/Work Type 
form. 

8. Management Reports: Remove Contract Type column from 
the Resource Configuration Report 



Exh. 2 - Page 3 



Change(s): 

(detailed description of 
change) - [add additional 
rows if multiple changes]) 



1. Job Entry-EWO: Develop Move Jobs-Contract functionality, 

1 . 1 User needs to be able to designate the state, CMC and wire 
center in which jobs should be moved. 

1 .2 Once the wire center is chosen, all job numbers, which 
have, open contact substeps belonging to that wire center 
should be displayed. 

1 .3 User needs to be able to identify the contract to which the 
job should be moved by providing the contract's effective 
date. This date must be a future date. 

1.4 User needs to be able to select and deselect the jobs to be 
moved. 

1 .5 Only jobs from one wire center may be moved at a time. If 
jobs from more than one wire center should be moved, the 
user must Save before selecting a new wire center. 

1 .6 Upon saving, the system should check to see if a valid 
master contract(s) for that wire center is effective for the 
date specified by the user. If not, error. 

1 .7 Information from this screen should be held in a until which 
time a batch process runs to re-configure the jobs identified 
to be moved. 



2. Job Entry-EWO: Batch Run 

2. 1 The batch process file should include the following information: 
the CMC, Effective Date, Job Number, Job Wire Center, Contract 
Number(s) and ContractorK) necessary for the batch program. It 
should also carry the associated CUID(s) of the persons 
requesting the Move feature. 

2.2 This batch program should run a modified configuration 
program. The purpose of this program is to replace the 
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existing contract number, CFs, CWI's on the substep level 
with the new contract(s). 
2.3 The program should check each "job wire center" to the 
Exhibit "C" wire center on any master contract(s) which are 
effective on the date supplied by the user. Once the 
contract(s) is found, the jobs should be reconfigured with the 
following stipulations. 

2.3.1 If the new contract number has the same contractor 
nickname as the old contract number, configuration 
should include both open and completed substeps on 
the job using the new contract number format. (This 
does not mean that CWI Codes are changed for 
completed substeps. It just means that they are 
considered when calculating the CWI's <groupings> 
for open substeps using the new contract. The 
completed substeps should remain in the data base with 
the old contract number and CWFs. (Any future 
added/deleted/changed substeps with subsequent 
configuration in Job Entry will have to include this 
factor. (A configuration override indicator on these 
substeps might be considered.) 

2.3.2 If the new contract number has a different contractor 
nickname, only open substeps are reconfigured. CWI 
groupings only apply to the open substeps on the job 
authorization. Again, completed substeps remain with 
the old contract number and remain in the database as 
they are presently populated. 
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2.4 Any substeps which fail configuration should not be 
moved, but will remain in the data base under the old 
contract number. A report of the reasons for each failure 
should be open mailed to the CUID of the person who 
requested the Move in the Job Entry - EWO. 

3. Job Entry-EWO Contract Date Field 

3.1 Provide a new field on the Encode a New Job form and the 
Job form to designate a Contract Date. This field is a date 
field (mm/dd/yyyy). Default to the current date. The user 
may overtype with a future date only. 

3.2 Presently, the configuration process uses the contract(s) 
which are in effect for the current date. If this field is 
populated with a future date, the process should look for the 
contract(s) which are in effect for that wire center on the date 
entered by the user. Whatever contract is in effect for that 
wire center on the Contract Date entered should be used. 

4. Job Entry-EWO: Contract Detail form 

4.1 Re-label form from Contract Bid to Contract Detail. 

4.2 This form should be redesigned similar to the example in the 
attachment which is a prototype from the Bid and Award 
module. 

4.3 The job contents area on both the top and bottom should be 
identical when the form is originally displayed. However, 
after that time, there is separate functionality. Either job 
contents area should be able to be expanded according to the 
business rules currently in place. Specifically, the job should 
be displayed with a contract number associated with that job 
in the tree. As folders are opened the prints and steps are 
displayed with the substeps finally being populated in the 
appropriate grid associated with that particular job content 
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tree. The grid heading should indicate which contract 
number is being displayed for the associated substeps. 

4.4 No grid should be populated specifically for the Bid Pool. 
Rather the bid pool should be displayed as another "contract 
number" in the contents form. Only when the bid pool folder 
is opened in the contents should the grid become active with 
the "Bid Pool" as its title. 

4.5 Substeps which are to be moved from the old contract 
number to the new contract number will be moved by using 
the "associate" icon. If the associate function is used, one of 
the grids must be blank with no focus in the contents form. 

4.6 The following is the users perspective of how the screen 
should operate when jobs are to be moved. 

4.6. 1 The user will open a folder in one of the 
contents form. 

4.6.2 The open substeps for that contract are displayed in 
the appropriate grid. 

4.6.3 The user will select the substeps in the grid by 
highlighting individual or a select all function. 

4.6.4 The associate icon will be clicked. 

4.6.5 The text box will be displayed and the user will 
enter the new contract number. 

4.6.6 Once the OK is selected, the "other 
contents form will be refreshed with the new 
contract number and the appropriate substeps 
which were chosen will be displayed. 

4.6.7 The user may select other substeps by "dragging" 
them to the new contract grid. This is a retention 
of the current method of moving substeps between 
contracts and bid pools. 
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4.6.8 If the user tries to open the same contract in both 
grids. Issue EMU: Contract XXXXX is currently 
open in one Move Grid. Cannot open in 2 nd grid. 

4.7 The user should only be allowed to move work between one 
contract to another without saving the work. Upon SAVE, 
the system should reconfigure the job using the same basic 
rules as the batch configuration process. 

4.7. 1 If the new contract number has the same contractor 
nickname as the old contract number, 
configuration should include both open and closed 
steps on the job using the new contract number 
format. 

4.7.2 If the new contract number has a different 
contractor nickname, only open substeps are 
considered in configuration. 

4.8 Once configuration is successful, the job contents area should 
return to its original condition. 

4.9 Using the above procedures, the user can move work from 
multiple contracts to single contracts or the reverse, by 
performing the function based on substeps. The above 
procedures will also allow the user to move jobs back to the 
old contract if it is decided that this is necessary. 

5. Job Entry-EWO: Change the configuration process 
5.1 Configuration should check each "job wire center" to the 
Exhibit "C" wire center on any master contract(s) which are 
effective on the date supplied by the user. Once the 
contract(s) is found, the jobs should be reconfigured with the 
following stipulations. 
5.1.1 If the new contract number has the same 

contractor nickname as the old contract number, 
configuration should include both open and 
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completed substeps on the job using the new 
contract number format, (this does not mean that 
CWI Codes are changed for completed substeps. It 
just means that they are considered within 
calculating the CWI" <groupings> for open steps 
suing the new contract. The completed substeps 
should remain in the data base with the old 
contract number and CWI 1 '. (any future 
added/deleted/changed substeps with subsequent 
configuration in Job Entry will have to include this 
factor. (A configuration override indicator on 
these substeps might be considered.) 
5.1.2 If the new contract number has a different 

contractor nickname, only open substeps are 
reconfigured. CWI groupings only apply to the 
open substeps on the job authorization. Again, 
completed substeps remain with the old contract 
number and remain in the data base as they are 
presently populated. 

Job Entry-EWO: Remove the functionality in configuration 

that uses the contract "type" logic. 

1 Since contract types may be different in a future environment 
that the current environment, the configuration processes 
should be modified to not use the contract "type" logic that is 
presently used. Rather the CI and CWI codes should 
determine the appropriate contract. 

2 Current logic = work_type -> rg_wca -> contract _type -> 
ospmcd (OSP contract) 

3 Proposed logic = work_type -> rg_wca -> ospmcd (OSP 
contract) -> contract_type 
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7. Configuration Editor: Remove the Contract Type field in 
configuration editor on the Resource Group/Work Type form. 

7.1 As a result of item 6, this field should be removed. 

8. Management Reports: Remove the Contract Type column 
from the Resource Configuration Report. 



Performance Requirements: 

(list any performance Performance should not be affected, 

requirements associated 
with this change) 



Dependencies: 

(list any defects or features 
that this enhancement is 
dependent on) 



Benefits: 

(provide benefits in dollars, Allows for the conversion to new master contracts, 
reduced headcount, time, 
savings, etc. for doing this 
work) 



Affected Components: (check) (check) 

Yes No 

RTOC Instructions 

HELP X 

User Guides X 

Testing X 

Infra-structure X 

Man agemen t Reports X 

Database X 
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Interfaces: 

(list any legacy or new None 
interface systems impacted 
by this change) 

Work-around: 

(is there a temporary work 
around??) 

(describe work around in 
detail) 

Risks: 

(list factors that impact, 
positive/negative, not doing 
this change) 

Business Rules: 

(list any business rules or 
constraints that should 
apply) 

Document Changes: 

(list affected documents 
requiring change) 

Acceptance Criteria/Test Scenario: 

(list test scenarios required 
to test change prior to user 
acceptance) REQUIRED 
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(check) (check) 
Yes No 



This is a show stopper. When a CMC renews a master contract, 
we presently do not have a method in OSPCM to convert to the 
new contract(s). 



Attachments: 

(copies of screens, reports, 
etc. before and after 
proposed change) 



Form prototypes for Encode a New Job and Contractor Work 

Items. 

Test scripts. 



Signatures of Agreement: 

(add additional rows if necessary) 

BAE: 

BAE: 

Team Manager: 
Team Lead: 
Analyst: 
Analyst: 
Analyst: 
Test Manager: 



Gail Deaton 
Ron Cochran 
Marty Smith 
Karin dinger 
Mark Shockey 
Mitra Partian 
Byron Thomas 
Kathy Klammer 
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BAE FUNCTIONAL REQUIREMENT DOCUMENT 

Table # 3640 



BAE Start Date: 
BAE Comp. Date: 
BAE Hours: 



December 4, 1996 
December 12, 1996 
18 



BAE Name: 
BAE Tele. No. 
LA Assigned: 



Carol A. Brechtel 
205-977-3611 
Karin Oinger 



CMVC Component Name: 



Reorg 



Associated Defect/Feature No.: 



3640 



Target Release: 

(give target release this 
needs to be in) 



2.0x 



Target Release Date: 

(give target release 
date for this 
enhancement) 



September, 1997 



Priority: 

(provide priority from 
'feature priority 5 list - 
production hi through 
deferred_low) 



Production hi 



Revision No.: 
Reason for Revision: 



Update spec with information from BAE/SME & Reorg Meetings 
(Revision Date: January 25, 1997, additional BAE hours 20) 
Update spec with information from functional walkthrough 
(Revision Date: June 17, 1997, additional BAE hours 3) 
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Subject: 

(brief description of change) Functionality to 1) rename a wire center 2) move wire 

centers/inventory sites between CMCs (Construction 
Management Center) 3) change resource id's assigned to the jobs 
that are involved in the reorg. 

Give the user the capability to create, update, delete, approve, 
unapprove, and search for reorg data. 

Due to the time frame allowed for development, reorgs across 
states have been deferred to a later release. 



Introduction: 

(description of what system The system does not handle the moving or renaming of wire 
currently does, what needs centers and/or inventory sites. Also can not mass update the 
to be changed, and why) resource id assigned to a job (a resource id assigned to a ajob can 

be changed in pre-survey). 

Enhance the system to handle wire center name changes, 
movement of wire centers/inventory sites between CMCs, and to 
handle changing resource id's assigned to work the jobs. 



At this time, the Reorg process will not provide for moving 
inventory to a new inventory site (inventory site rename). 
The entire inventory site can be moved to a new CMC, buts 
name must remain the same. 
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Solution: 

(describe what the system 
will or should do and any 
general constraints or 
conditions that limit the 
solution) 



1 . New user screens to handle the renaming of wire centers, the 
movement of inventory sites and wire centers between CMCs, 
and the changing of resource ids. Capability of new screens, 
create a new reorg, update or delete an existing reorg, approve 
a reorg, unapprove a reorg, and the ability to search for an 
existing reorg. 

2. Crystal Report to printout the requested reorg information 
(possibility exist of handling more than one reorg request at a 
time). 

3. Reports to list all jobs involved in the reorg. These reports 
could be run before the reorg and again after the reorg to 
ensure that all data was moved properly. 

4. Batch runs that will move/update the data in the data bases. 



Change(s): 

(detailed description of 
change) - [add additional 
rows if multiple changes] 



Types of reorgs/changes : 

1 . CMC consolidation 

2. Wire Centers and inventory sites split between two or more 
CMCs (CMC split) 

3. Resource ID changed in associated with wire center move 

4. Wire Center Name Change 



If the reorg involves adding a new CMC or deleting an existing 
CMC, the following must be done prior to running the reorg: 

1 . update the routing rules in the navigator cat tables 

2. add the new CMC to the location tables, if applicable (this 
must be done prior to requesting the reorg) 

The following OSPCM executables will probably be affected by 
the reorg: 
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Billing & Reporting, Complaints, Employee Editor, Inspections, 
Job Entry EWO, Job Entry Other, Location Editor, OPF Editor, 
Pricing, Scheduling, Bid & Award, Work Station, and Materials 
Management. 

Wire Center Name Change (reorg Type #4): 

Wire Center name changes are performed when the state has a 
NPA split. 

The process should do the following: 

1 . End date the old wire center. 

2. Create a new wire center based on the associated data from 
the old wire center (the new wire center name is equal to the 
new NPA + last three characters of the old wire center name) 

3. Update all occurrences of the old wire center name in various 
OSPCM tables with the new wire center name by replacing 
the first three characters of the old wire center name with the 
new NPA. 

• Types of tables affected (These are "groups" of tables not the 
names of the tables. This may not be an inclusive list-any 
containing a wire center name may need to be reorged. The 
actual tables to be reorged will be determined during detail 
design.): 

• Location tables (including the LMOS wire centers 
associated to the wire centers being renamed) 

• Contract tables (including Exhibit C section of any 
contracts and the inspection pool associated to the wire 
centers being renamed) 

• Job tables (update all jobs, regardless of status) 

• Configuration tables 
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Example of a wire center name change: all wire centers in KNVL 
Tennessee currently have a NPA of 615XXX, after the NPA split, 
all wire centers in KNVL, Tennessee have a NPA of 423XXX. 
The process would need to end date the old 615XXX wire centers 
and build new wire centers with the 423XXX NPA. The batch 
process would need to update all occurrences of the old wire 
center name with the new wire center name. 
CMC Consolidation, Wire Centers/Inventory Site Splits and 
Resource ID changes (Reorg Types #1, #2 & #3): 

The process should do the following when inventory sites and/or 
wire centers are moved: 

1 . Update all occurrences of the old CMC with the new CMC in 
various OSPCM tables. 

• Types of tables affected (These are "groups" of tables not the 
names of the tables. This may not be an inclusive list-any 
containing a CMC may need to be reorged. The actual tables 
to be reorged will be determined during detail design.): 

• location tables 

• job tables (update all jobs, regardless of status) 

• configuration tables 

• pricing tables 

• contract tables (including inspection tables and 
complaints) 

• scheduling tables 

2. Update resource id's assigned to open substeps involved in 
the reorg. The user would provide the information for these 
changes by populating the Resource Id window. 

Job Entry - if all wire centers on a job are being moved to the 
same CMC the process should change the primary CMC to the 
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new CMC, at the job header level If the wire centers on a job are 
being split between two or more CMCs-the primary CMC should 
be changed to the CMC of the primary wire center shown on the 
job header. 

Pricing - The CMC is used when printing reports. The CMC 
should be updated in pricing identical to the change made in job 
entry. 

Configuration - Three configuration tables need to be updated 
when the reorg is done, the tables are: 

• RG_WCA - change only the resource id assigned to the wire 
center area 

• RGJWORK TYPE - copy all wire centers over and fill in 
any not yet existing. 

• RG_WORK_TYPE_WCA - change on the resource id 
assigned to the wire center area. 

Employee - the filed user will need to build all new employee 
data before the resource id screen can be populated. When 
updating employee data with the new CMC and/or resource id the 
user must use the same effective date as the reorg. The changes 
made in the employee editor will build future employee records. 
After all new resource id are built the reorg resource id screen 
may be populated by the user. 

It is important to note that the resource id's will only be update on 
open substeps. Closed, completed substeps will not be updated 
with the new resource id. 
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Workstation - all jobs should be moved to the new CMC, using 
the same procedures as indicated for job entry. 

Inspections - CMC information is stored on the inspection 
tables, when the reorg process is run it will be necessary to update 
the with the new CMC. If wire centers are being split between 
multiple CMC, the process will need to read the wire center to 
determine which CMC to use. It may be necessary for the 
contract co-ordinator to re-build inspection pools after the reorg is 
executed. 

Location Editor - Move inventory site and wire centers to the 
new CMC, and end date the old CMC if all associated wire 
centers and inventory sites are moved. If all inventory sites and 
wire centers are not being moved, the CMC should stay active. 

Billing and Reporting - All jobs (open, closed, completed, etc.) 
should be moved. This included all job types: BSW, EWO and 
RW. 

Job Entry Other - All jobs (open, closed, completed, etc.) 
should be moved. This included all job types: BSW, EWO and 
RW. 

Scheduling - Scheduling reads the job entry tables, so when they 
are updated by the reorg process and when the schedule is run it 
should pick up the correct data. 

The following processes should be run after the reorg is complete: 
1 . If the user adds a new scheduling area (manual effort), a 
process named CrStndCTypes should be executed. This 
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process updates the CMC drop-down list in the Job Entry 
Commitment grid on the substep screen. 
2. The schedule should be run for all CMC's involved in the 
reorg. 

Materials Management - If an inventory site is being moved to 
a new or existing CMC, the inventory site name is not being 
changed, the process needs to change the CMC name associated 
with the inventory site. The inventory (serialized and non- 
serialized), orders, transfer requests, shipments, and material 
inventory transactions would stay with the inventory site. 

If the user wants to move inventory at one site to another 
inventory site or multiple inventory sites the user will need to 
manually move the inventory (serialized and non-serialized) using 
the transfer process and end-date the old inventory site, if 
applicable. 

The main thing to remember in this execuis to change the 
association of the inventory site to the new CMC, if the inventory 
site is being moved in the reorg. All inventory (serialized and 
non-serialized) will stay with the inventory site but the inventory 
site will be associated with the new CMC. 

The possibility exists for the reorg to only move wire centers, if 
no inventory sites are being moved the reorg will not effect this 
executable. 

Example: Inventory Site IV1 is being moved from CMC1 to 
CMC2, the process would need to change the association of INV1 
from CMC1 to CMC2. 
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The following functionality is needed in the presentation : 

1 . Allow the user to search for reorg requests by State and 
(Reorg Number, CMC and/or Effective Date) 

2. Allow the user to provide the new NPA, if applicable. 

3. Allow the user to select/deselect a wire center to 
rename/move, if applicable. 

4. Allow the user to select/deselect an inventory site to move, if 
applicable. 

5. Allow the user to provide the CMC to which the wire 
center/inventory site should be moved, if applicable. 

6. Allow the user to provide the new resource ids that should be 
assigned to the jobs in the wire center being moved, if 
applicable. 

7. Allow the user to provide an effective date for the Reorg 

• The effective date is defined as the date the Reorg batch 
process should run. 

Security : 

1 . Only user types of 247, 23 1 , or 232 can create, update, or 
delete a reorg request prior to approval 

• A 247 user can only update or delete those reorg requests 
that he/she originated 

• A 23 1 or 232 user can update or delete any reorg request. 

2. Only user types of 23 1 or 232 can approve or unapprove a 
reorg request 

• A 23 1 or 232 user can approve or unapprove any reorg 
request. 

3. Any user that has access to the Reorg Application can view 
reorg requests 

4. If user has security for all states, the state drop down lists all 
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nine states; otherwise, just the states for which he/she has 
security should be listed. Therefore, if a user only has 
security for FL, he can only request reorgs or view reorg 
requests for FL. 

Edits : 

1 . When the reorg is approved, it is locked, the system will allow 
a user to view the data associated with the reorg, but no 
changes can be made. 

2. Updates/Cancellations cannot be made to the request once it 
has been approved. A Core Staff user or the OSPCM 
Administrator must first unapprove the reorg. After the reorg 
is unapproved the updates/cancellation may be made by the 
user. 

3. The reorg will not run unless it has been approved. 

4. Resource Ids and CMCs must exist, have a start date equal to 
the effective date of the reorg, and must not be end-dated. 
The effective date of the reorg is the date the reorg will 
process. j 

5. Effective Date must be a future date and must be a Saturday 
(future employee records need to be created for a Saturday so 
that they may continue to work in the old CMC on Friday) 

6. Verify that there is not already an overlapping reorg request in 
existence. 

• Perform verification at the time reorg details are saved 

• Verification should be done on only the requests that have 
not been processed (doesn't matter if it has been approved or 
not) 

• Overlapping Reorg requests are determined as follows: 
• If there is more than one request to rename the 

same wire center (e.g., request to rename wcl to wc2 and 
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another request to rename wcl to wc3) 

• If there is more than one request to move the same 
wire center (e.g., request to move wcl to CMC1 and another 
request to move wcl to CMC2) 

• If there is more than one request to move the same 
inventory site (e.g., request to move is 1 to CMC1 and another 
request to move is 1 to CMC2) 

• Display an error message if there is an overlapping reorg 
request. 



Performance Requirements: 

(list any performance 
requirements associated 
with this change) 



All updates must be made over the week-end. Reorg could begin 
on Saturday morning completing on Sunday so the users could 
verify that all data was updated correctly. System must be 
available on Monday morning, normal working hours. 



Dependencies: 

(list any defects or features None, 
that this enhancement is 
dependent on) 



Benefits: 

(provide benefits in dollars, Keep wire center names current and accurate. Keep the system in 
reduced headcount, time line with realignment of districts, managers, etc. 
savings, etc. for doing this 
work) 
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Affected Components: (check) (check) 

Yes No 

RTOC Instructions X 

HELP X 

User Guides X 

Testing X 

Infra-structure X 

Management Reports X 

Database X 



Interfaces: 

(list any legacy or new Majority of systems that interface with OSPCM would need to 

interface systems impacted by know about the changes we were making. In today's 
this change) environment this is done by letters to MTR, STAR, Financial 

Processing, BCAS, Asset Management etc. Any change 
moving or renaming wire centers in OSPCM would need to be 
coordinated with OPEDS. For a Wire Center name change 
OSPCM would need to coordinate the change with LMOS. 



Work-Around: (check) (check) 

Yes No 

(is there a temporary work X 
around??) 

(describe work around in 
detail) 
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Risks: 

(list factors that impact, Don't rename the wire centers when area code splits are done, 

positive/negative, not doing don't move wire centers and inventory sites when CMCs are 
this change) combined or split. Management would be difficult since it 

would be almost impossible to pull data on the location you are 
responsible for. The user would also be required to manually 
update the resource id assigned to work a substep when changes 
are made. 



Business Rules: 

(list any business rules or 
constraints that should apply) 



1 . If adding a new CMC, it must be built using the Location 
Editor prior to the Reorg being requested. 

2. Resource Ids and future dated employee records must be 
created prior to the Reorg being requested (this includes both 
craft and supervisors). 

3. All jobs (open, closed, cancel, etc.) should be updated with 
the new (TO) CMC if a CMC consolidation or split is 
executed. 

4. All jobs (open, closed, cancel, etc.) should be updated with 
the new wire center name if a wire center name change is 
executed. 

5. Resource Ids should be changed on all "open" substeps on all 
"open" jobs if a CMC consolidation or split is executed. Do 
not update resource ids on completed and closed 
jobs/substeps. 

6. A Reorg cannot be done below a wire center level. 

7. When moving a wire center to a new CMC, the user must 
assign new resource ids. 

8. A CMC consolidation is defined as combining the wire 
centers of one or more CMCs into one CMC. 
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9. A CMC consolidation MUST involve a wire center and 
inventory site move. 

10. The old CMC must be end-dated in a CMC consolidation; 
therefore a CMC consolidation involves moving all of the 
wire centers and all of the inventory sites from the old 
CMC(s) to the new CMC. 

1 1 . A CMC split is defined as moving some or all of the wire 
centers and/or inventory sites of one CMC to one or more 
difference CMCs. 

12. A CMC split does not require inventory sites to be moved. 

13. The old CMC may be kept in a CMC split. 

14. Management Reports will not be involved in the reorg 
process (reports should be requested through the Reorg 
Application). 

15. The reorg should not generate duplicate job numbers. 

16. System should be backup before the reorg is run. 

17. Regional Contract, BSW LookUp and the Holiday Editor do 
not need to be updated with the reorg process. 

No documentation exists for this process. Would need to 
develop M&P, test scenarios and functional decomps. 



Documentation Changes: 

(list affected documents 
requiring change) 



test change prior to user 
acceptance) 



Acceptance Criteria/Test Scenario: 

(list test scenarios required to 1 . Rename several wire centers. 

2. Change resource id assigned to do work on jobs. 

3. Move all of the wire centers and all of the inventory sites 
from two or more CMCs to a new or existing CMC (delete 
old CMCs) 

4. Move all of the wire centers and all of the inventory sites 
from one CMC to a new or existing CMC (delete old CMC). 
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5. Move some of the wire centers from one CMC to a new or 
existing CMC (keep old CMC) 

6. Move some of the wire centers and some of the inventory 
sites from one CMC to a new or existing CMC (keep old 
CMC). 

7. Move some of the wire centers from one CMC to 2 or more 
new or existing CMCs (keep old CMC). 

8. Move some of the wire centers and some of the inventory 
sites from one CMC to 2 or more new or existing CMCs 
(keep old CMC) 

9. Move all of the wire centers and all of the inventory sites 
from one CMC to 2 or more new or existing CMCs (delete 
old CMC). 

10. Move some of the inventory sites from one CMC to a new or 
existing CMC (keep old CMC). 

11. Move some of the inventory sites from one CMC to 2 or 
more new or existing CMCs (keep old CMC). 

DETAILED TEST SCENARIOS WILL BE FURNISHED AT A 
LATER DATE. 



Attachments: 



(copies of screens, reports, 
etc. before and after proposed 
change) 



Screen layouts (wire center name change, wire center and 
inventory site moves, and resource id changes) Several of the 
editors required on each screen is also on the screen layouts. 
Manual Reorg Efforts 
Open/Closed Issues 



Signatures of Agreement: 

(add additional rows if necessary) 



BAE: 



Lead Analyst: 
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BAE FUNCTIONAL REQUIREMENT DOCUMENT 



Table # 6622 FS 



BAE Start Date: 06/24/97 
BAE Comp. Date: 06/24/97 
BAE Hours: 2 



BAE Name: 
BAE Tele. No.: 
LA Assigned: 



Terry L. Small 
205-977-3613 



CMVC Component Name: 



Interfaces extracts mtr 



Associated Defect/Feature No.: 



6622 



Target Release: 

(give target release this 
needs to be in) 



2.01 



Target Release Date: 

(give target release ASAP 
date for this 
enhancement) 



Priority: 

(provide priority from 
'feature priority 5 list - 
production_hi through 
deferred_low) 



Production hi 



Revision No.: 
Reason for Revision: 



Subject: 

(brief description of change) 1 . Reduce MTR error list before processing errors in OSPCM 
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Introduction: 

(description of what system 
currently does, what needs 
to be changed, and why) 



1 . Currently MTR send all errors in the company to OSPCM. 
When OSPCM processes all of the errors trying to determine 
whether the errors belong to OSPCM or not, it causes lock out 
problems for the users whenever this process is run. 



Solution: 

(describe what the system 
will or should do and any 
general constraints or 
conditions that limit the 
solution) 



1 . Add code to perform the edits of whether the MTR error 
should be displayed in OSPCM prior to actually doing the 
process that is causing our lock outs to the user. This process 
should also reduce the errors displayed to only include 
construction time reporting craft and I&M reporting errors 
that were sent to MTR through OSPCM only. 



Change(s): 

(detailed description of Determine if error is a reporting error that belongs to OSPCM and 

change)-[add additional display only the errors that belong to OSPCM. Make sure 

rows if multiple changes) processing is done so as not to create locking problem for 

the users community. It will probably be best to perform 
these edits by social security number against the 'CRAFT' 
employee in OSPCM. It may be a requirement to also 
check against the daily work report record for the date 
under report for those that have a labor type of I&M in the 
craft employee table. 
If there is an error from MTR that belongs to an OSPCM craft 
employee that has a 'labor type' equal to I&M we need to 
display this error. If the error from MTR is for a labor 
type I&M and there is no work report for that date under 
report in OSPCM, do not display the error. 
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Display all errors for 'labor types' not equal to CLERICAL and 
I&M except for case identified in 2 above. 



Performance Requirements: 

(list any performance 1 . 

requirements associated 
with this change) 



Must eliminate locking problems with this process. This 
process should take as little time as required so as not to 
interfere with anything else being processed at the same time. 
It should be done as early as possible, preferably before 7:00 
am eastern time. 



Dependencies: 

(list any defects or features 1. None 
that this enhancement is 
dependant on) 

Benefits: 

(provide benefits in dollars, 1 . Eliminate locking problems. 

reduced headcount, time 2. Reduce errors from MTR to a point that we only display errors that 

will apply to OSPCM. 

savings, etc. for doing this 
work) 

Affected Components: (check) (check) 

Yes No 

RTOC Instructions 

HELP X 

User Guides X 

Testing X 

Infra-structure 

Management Reports 

Database 



Exh. 2 - Page 30 

\ 



Interfaces: 

(list any legacy or new 1 . MTR interface for error processing, 

interface systems impacted 
by this change) 



Work-around: (check) (check) 

Yes No 

(is there a temporary work X 
around??) 

(describe work around in 
detail) 



Risks: 

(list factors that impact, 1 . If not implemented, the user will lose access with OSPCM 
positive/negative, not doing during these lock out problems, 

this change) 2. System will not be deployed. 



Business Rules: 

(list any business rules or 1 . OSPCM will not edit that I&M actually reported time for the 
constraints that should day. It will only process errors for time actually reported 

apply) through OSPCM for I&M employees. 

2. Construction employees will get errors on reports sent to 
MTR and for not reporting to MTR. 



Documentation Changes: 

(list affected documents 1. Workstation 
requiring change) 
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Acceptance Criteria/Test Scenario: 

(list test scenarios required to 1 . Enter time reporting for labor type of I&M. 

1 . 1 Create one report with errors and one report 

without errors. 



test change prior to user 
acceptance) REQUIRED 



1 .2 Process through MTR 

1 .3 Should get error for only one that was reported 
with errors. 

1 .4 Also verify that employees with labor type of 
I&M that do not report time for the day through 
MTR do not get errors back into OSPCM. 

2. Enter time reporting for regular time reporting construction 
craft person. 

2.1 Create one report with errors, one report without 
errors and a craft person with no report. 

2.2 Process through MTR 

2.3 Should get error on report with errors, error on 
person that did not report, and no error on report 
with no errors. 

3. Verify OSPCM does not display any errors that were not 
time reported through OSPCM. 



Attachments: 

(copies of screens, reports, 1 . None 
etc. before and after 
proposed change) 
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Signatures of Agreement: 

(add additional rows if necessary) 
BAE: 

Lead Analyst: 



BAE FUNCTIONAL REQUIREMENT DOCUMENT 



Table # 6427 FS 



BAE Start Date: 
BAE Comp. Date: 
BAE Hours: 



05/20/1997 
05/30/1997 
3 



BAE Name: 
BAE Tele. No.: 
LA Assigned: 



Mark Seal 
205-977-3618 



CMVC Component Name: 



CHANGE MGMT 



Associated Defect/Feature No. 



6427 



Target Release: 

(give target release this 
needs to be in) 



2.1 



Target Release Date: 

(give target release 
date for this 
enhancement) 



Priority: 

(provide priority from 
'feature priority' list - 
productionhi through 
deferred_low) 



PROD 
HI 



Revision No.: 
Reason for Revision: 



Subject: 

(brief description of change) 1 . CHANGE DEFAULT INVENTORY SITE 
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Introduction: 

(description of what system 

currently does, what needs 

to be changed, and why) 

ASSIGNED BASED ON THE RES ID ASSIGNED. IF 
THERE ARE MULTIPLE RES ID'S IN THE 
CONFIGURATION THE SYSTEM WILL ASSIGN ONE 
AT RANDOM. THE USER CAN, AFTER 
CONFIGURATION, CHANGE THE RES ID. THE 
PROBLEM IS THAT THE DEFAULT INVENTORY SITE 
DOES NOT CHANGE. 



1. DURING CONFIGURATION A RES ID IS ASSIGNED TO 
EACH ACTIVITY ON A JOB. ALSO DURING 
CONFIGURATION A DEFAULT INVENTORY SITE IS 



Solution: 

(describe what the system 
will or should do and any 
general constraints or 
conditions that limit the 
solution) 



1. WHEN THE USER CHANGES THE CONFIGURATION 
AS SINGED RES ID AND THE MATERIAL IS NOT 
ALREADY ON ORDER THEN CHANGE THE DEFAULT 
INVENTORY SITE. 



Change: 

(detailed description of 
change)-[add additional 
rows if multiple changes] 



1 . CHANGES SHOULD APPLY TO THE ACTIVITY MTCE 
SCREEN IN PRESURVEY AND IN SCHEDULING. 

2. CHANGE THE SYSTEM SO THAT WHEN A USER 
CHANGES THE RES ID ASSIGNED TO AN ACTIVITY, 
AND THE MATERIAL HAS NOT BEEN ORDERED FOR 
THE ACTIVITY, THEN THE DEFAULT INVENTORY 
SITE SHOULD ALSO BE CHANGED TO THE DEFAULT 
INVENTORY SITE OF THE NEW RES ED. 

3. IF NO DEFAULT INVENTORY SITE EXISTS FOR THE 
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ASSINGED RES ID FROM CONFIGURATION AND THE 
USER CHANGES THE RES ID, AND THE MATERIAL 
HAS NOT BEEN ORDERED THEN THE SYSTEM 
SHOULD TRY TO ASSIGN THE DEFAULT INVENTORY 
SITE FOR THE NEW RES ID. 

4. IF WHEN TRYING TO CHANGE THE DEFAULT 
INVENTORY SITE FOR A NEWLY ASSINGED RES ID 
AND THAT NEW RES ID DOES NOT HAVE A DEFAULT 
INVENTORY ASSIGNED THEN DON'T CHANGE THE 
INVENTORY SITE. 

5. FOR THOSE SUBSTEPS THAT HAVE MATERIAL THAT 
HAS BEEN ORDERED DO NOT CHANGE THE 
INVENTORY SITE. 



Performance Requirements: 

(list any performance 1. NONE 

requirements associated 
with this change) 



Dependencies: 

(list any defects or features 1 . NONE 
that this enhancement is 
dependent on) 
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Benefits: 

(provide benefits in dollars, 
reduced headcount, time 
savings, etc. for doing this 
work) 

Affected Components: 

RTOC Instructions 
HELP 
User Guides 
Testing 

Infra-structure 
Management Reports 
Database 

Interfaces: 

(list any legacy or new 
interface systems impacted 
by this change) 

Work-Around: 

(is there a temporary work 
around??) 

(describe work around in 
detail) 



1 . THIS WILL SAVE THE USER TIME IN ASSIGNING AN 
ALT INV SITE IN THE MATERIAL MODULE. MOSTLY, 
THE FIELD USERS WILL FORGET AND MATERIAL 
WILL NOT GET ORDERED ON TIME OR TO THE 
CORRECT INVENTORY SITE. 



X 



(check) (check) 
Yes No 



X 
X 
X 



1. N/A 



(check) (check) 
Yes No 

X 

1. THE WORK AROUND IS FOR THE 
USER TO ASSIGN AN ALT 
INVENTORY SITE. IF THE USER 
FORGETS TO DO THIS THEN THE 
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MATERIAL WON'T GET 
ORDERED ON TIME. 



Risks: 

(list factors that impact, 1 . THE USER WILL HAVE TO ASSIGN AN ALT 
positive/negative, not doing INVENTORY SITE. IF THE USER FORGETS TO DO 
this change) THIS THEN THE MATERIAL WON'T GET ORDERED 

ON TIME AND/OR TO THE CORRECT INVENTORY 

SITE. 



Business Rules: 

(list any business rules or 1 . THESE CHANGES SHOULD APPLY TO THE ACTIVITY 
constraints that should MTCE SCREEN IN PRESURVEY AND IN SCHEDULING, 

apply) 



Documentation Changes: 

(list affected documents 1 . USER GIDES AND HELP SCREENS 
requiring change) 



Acceptance Criteria/Test Scenario: 

(list test scenarios required 1 . ENTER AND CONFIGURE A JOB SO THAT THE 
to test change prior to user CONFIGURATION PROCESS ASSIGNS A RES ID (A) 

acceptance) REQUIRED AND A DEFAULT INV SITE (A) TO AN ACTIVITY. IN 

PRESURVEY ON THE ACTIVITY MTCE SCREEN 
CHANGE THE RES ID (A) FOR THE ACTIVITY TO A 
NEW RES ID (B) AND VERIFY THAT THE DEFAULT 
INV. SITE IS CHANGED TO (B) 
2. ENTER AND CONFIGURE A JOB SO THAT THE 
CONFIGURATION PROCESS ASSIGNS A RES ID (A) 
AND A DEFAULT INV SITE (A) TO AN ACTIVITY. 
CHANGE THE RES ID (A) TO A NEW ONE (B) THAT 
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DOES NOT HAVE A DEFAULT INV. SITE ASSIGNED. 
EXPECTED RESULT. . .IS THAT THE RES ID (A) GETS 
CHANGED TO RES ID (B) AND THE DEFAULT INV 
SITE (A) DOES NOT. 

3. ENTER AND CONFIGURE A JOB SO THAT THE 
CONFIGURATION PROCESS ASSIGNS A RES ID (A) 
AND THERE IS NO DEFAULT INV SITE ASSIGNED TO 
AN ACTIVITY. CHANGE THE RES ID (A) TO A NEW 
RES ID (B) THAT HAS A DEFAULT INV SITE (B). 
EXPECTED RESULTS. . .THE RES ID AND THE 
DEFAULT INV. SITE GET CHANGED TO (B). 

4. THESE TESTS SHOULD BE PERFORMED ON THE 
ACTIVITY MTCE SCREEN IN PRESURVEY AND IN 
SCHEDULING. 

Attachments: 

(copies of screens, reports, 1. NONE 
etc. before and after 
proposed change) 

Signatures of Agreement: 

(add additional rows if 

necessary) 

BAE: 

Lead Analyst: 
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BAE FUNCTIONAL REQUIREMENT DOCUMENT 



Table #6436 FS 



BAE Start Date: 
BAE Comp. Date: 
BAE Hours: 



05/21/1997 
05/30/1997 
6 



BAE Name: 
BAE Tele. No.: 
LA Assigned: 



Mark Seal 
205-977-3618 



CMVC Component Name: 



CHANGE MGMT 



Associated Defect/Feature No. 



6436 



Target Release: 

(give target release this 
needs to be in) 



2.1 



Target Release Date: 

(give target release 
date for this 
enhancement) 



Priority: 

(provide priority from 
'feature priority' list - 
productionhi through 
deferredlow) 



PROD- 
HI 



Revision No.: 
Reason for Revision: 



Subject: 

(brief description of change) 



1 . ADD EDITS TO THE PRESURVEY SCREEN WHEN 
ADDING ROADBLOCKS FOR FACTORY ADD ON 
ITEMS ASSOCIATED WITH AN ASSEMBLY 
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Introduction: 

(description of what system 1 . CURRENTLY THE SYSTEM WILL ALLOW A 
currently does, what needs to ROADBLOCK TO BE PLACED ON A SUBSTEP THAT 
be changed, and why) HAS A FACTORY ADD-ON MATERIAL ITEM. 

BECAUSE THE SYSTEM WILL AUTO COMPLETE THE 
FACTORY ADD-ON SUBSTEPS, NO OTHER 
COMPLETION PROCESSING WILL OCCUR. THIS 
MEANS THAT IF A ROADBLOCK EXISTED IT WOULD 
NOT BE AUTOMATICALLY CLEARED WHEN THE 
FACTORY ADDOON SUBSTEP IS AUTO COMPLETED. 



Solution: 

(describe what the system 1 . DON'T ALLOW A ROADBLOCK TO BE ENTERED 
will or should do and any FROM THE PRESURVEY SCREEN ON A SUBSTEP 

general constraints or THAT HAS FACTORY ADD-ON MATERIAL ASSIGNED 

conditions that limit the 
solution) 

Change(s): 

(detailed description of 1. ADD AN EDIT ON THE PRESURVEY SCREEN. WHEN 

change)-[add additional rows THE USER ATTEMPTS TO ENTER A ROADBLOCK 
if multiple changes]) THE SYSTEM SHOULD CHECK THE MATERIAL 

ASSIGNED TO THE SUBSTEP. IF THE MATERIAL 
HAS AN ASSEMBLY INDICATOR SET TO "Y" IN THE 
OSPCM MATERIAL ITEM THEN DO NOT ALLOW THE 
ROADBLOCK TO BE ENTERED. RETURN A 
MESSAGE "ROADBLOCK NOT ALLOWED ON A 
SUBSTEP WITH FACTORY ADD-ON MATERIAL. 
ENTER THE ROADBLOCK ON THE ASSOCIATED 
CABINET". 
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Performance Requirements: 

(list any performance 1. NONE 

requirements associated with 
this change) 



Dependencies: 

(list any defects or features 1. NONE 
that this enhancement is 
dependant on) 



Benefits: 

(provide benefits in dollars, 
reduced headcount, time 
savings, etc. for doing this 
work) 



1 . WITHOUT THIS EDIT WE HAVE NO WAY TO ENSURE 
THAT ROADBLOCKS WILL BE CLEARED ON ALL 
CLOSED JOBS. THAT MEANS THAT THE 
ROADBLOCK REPORT COULD HAVE ROADBLOCKS 
FOR CLOSED JOBS. IF THIS HAPPENS THERE IS 
CURRENTLY NO WAY TO REMOVE THESE 
ROADBLOCKS. 



Affected Components: (check) (check) 

Yes No 

RTOC Instructions X 

HELP X 

User Guides X 

Testing X 

Infra-structure 

Management Reports 

Database 



Exh. 2 - Page 42 



Interfaces: 

(list any legacy or new 1. NONE 

interface systems impacted by 
this change) 

Work-around: (check) (check) 

Yes No 

(is there a temporary work X 
around??) 

(describe work around in 
detail) 

Risks: 

(list factors that impact, 1 . IF THIS CHANGE IS NOT MADE ROADBLOCKS 
positive/negative, not doing COULD APPEAR ON THE ROADBLOCK REPORT 

this change) AND IN THE SYSTEM THAT CANNOT BE REMOVED. 



Business Rules: 

(list any business rules or 1 . ROADBLOCKS ASSOIC ATED WITH AN ASSEMBLY 

constraints that should apply) SHOULD BE ON THE SUBSTEP WITH THE CABINET 

ASSIGNED. 
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Document Changes: 

(list affected documents 
requiring change) 



1. USER GUIDES, HELP, M&P 



Acceptance Criteria/Test Scenario: 

(list test scenarios required to 1 . ENTER A JOB WITH SEVERAL SUBSTEPS THAT 
test change prior to user MAKE UP AN ASSEMBLY. GO TO THE PRESURVEY 

acceptance) REQUIRED SCREEN AND TRY TO ENTER A ROADBLOCK ON A 

SUBSTEP THAT HAS FACTORY ADD-ON MATERIAL 
ASSIGNED. THE ERROR "ROADBLOCK NOT 
ALLOWED ON A SUBSTEP WITH FACTORY ADD-ON 
MATERIAL. ENTER THE ROADBLOCK ON THE 
ASSOCIATED CABINET" SHOULD DISPLAY. 
2. TRY TO ENTER THE ROADBLOCK ON THE SUBSTEP 
THAT HAS THE CABINET ASSIGNED. THIS SHOULD 
BE ALLOWED. 



Attachments: 

(copies of screens, reports, 1 . NONE 
etc. before and after proposed 
change) 

Signatures of Agreement: 

(add additional rows if 

necessary) 

BAE: 

Lead Analyst: 
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BAE FUNCTIONAL REQUIREMENT DOCUMENT 



Table # 6501 



BAE Start Date: 
BAE Comp. Date: 
BAE Hours: 



June 5, 1997 
June 6, 1997 
6 Hours 



BAE Name: 
BAE Tele. No.: 
LA Assigned: 



Carol A. Brechtel 
205-977-3611 



CMVC Component Name: 



MATMGMT 



Associated Defect/Feature No. 



6501 



Target Release: 

(give target release this 
needs to be in) 



Target Release Date: 

2 . 1 (give target release 

date for this 
enhancement) 



9/1997 



Priority: 

(provide priority from 
'feature priority' list - 
production_hi through 
deferred_low) 



Production hi 



Revision No.: 
Reason for Revision: 



Subject: 

(brief description of change) 1 . Enhance the system to allow the user to save the 801 0, 6241 

and 1010 forms to a file, for printing at a later date. 
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Introduction: 

(description of what system 
currently does, what needs 
to be changed, and why) 



1 . Today whenever non-COE equipment is transferred between 
inventory sites the system automatically generates a RF-6241- 
Ml form. 

2. When COE equipment is: 
transferred between inventory sites 
*assigned to a job from existing inventory 
*unassigned from a job 

3. When material (COE and non-COE) is returned to a 
BST/GTES warehouse or an outside vendor the system 
automatically generates a RF-1010-A1. 

4. Enhance the system to allow these forms to be saved to a file 
so they can be printed at a later date. 



Solution: 

(describe what the system 
will or should do and any 
general constraints or 
conditions that limit the 
solution) 



1 . The system should give the user the option of 

* printing the form 

* save the form to a file 

* print the form and save it to a file 



Change(s): 

(detailed description of 
change)-[add additional 
rows if multiple changes] 



1 . Enhance the system to display a window, before 
automatically generating any of the forms (8010, 6241 & 
1010) giving the user a selection of: 

* print the form only 

* save the form to a file 

* print the form and save the form to a file 

2. This will allow the user to print the form if they are ready to 
ship the cable. They can send the form to a file that can be 
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printed later or they can keep for the office record copy. By 
allowing the user to create the file they have no need to keep a 
paper copy of the form. 



Performance Requirements: 

(list any performance 1 . There should be no noticeable affect on performance, 

requirements associated 
with this change) 

Dependencies: 

(list any defects or features 1 . NONE 
that this enhancement is 
dependent on) 

Benefits: 

(provide benefits in dollars, 
reduced headcount, time 
savings, etc. for doing this 
work) 

they need, for remote locations this may be easier than 
making copies. 



1 . Allow the user to save the forms to be printed later or they 
could save the file for their records. Eliminate the need for a 
paper copy. 

2. Also if multiple copies are needed they can print as many as 
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Affected Components: (check) (check) 

Yes No 
RTOC Instructions X 
HELP X 
User Guides X 
Testing X 
Infra-structure X 
Management Reports X 
Database X 



Interfaces: 

(list any legacy or new 1 . NONE 

interface systems impacted by 
this change) 



Work-around: (check) (check) 

Yes No 

(is there a temporary work X 
around??) 

(describe work around in 1 . The user would need to make a copy 

detail) for future use. 



Risks: 

(list factors that impact, 1 . If the form is printed when the transaction is done and the 

positive/negative, not doing material is not shipped the paper work could get lost, 

this change) 2. 8010 may not be handled correctly and DCPR would not get 

the data they need to keep their records accurate. 
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Business Rules: 

(list any business rules or 
constraints that should apply) 



1. 



Give the user a choice whenever the form is generated by 
the system. 



Documentation Changes: 

(list affected documents 1 . User Guide updated with the new window and process 

requiring change) 2. Test Scenarios and Functional Decomps 



test change prior to user 
acceptance) REQUIRED 



Acceptance Criteria/Test Scenario: 

(list test scenarios required to 1 . Generate the following transactions and print a 8010, save 

the 8010, and print and save the 8010: 

• assign COE equipment to a job from existing inventory 

• unassign COE equipment from a job 

• transfer COE equipment between inventory sites 

2. Generate the following transactions and print a 6241, save 
the 6241 , and print and save the 6241 : 

• transfer non COE equipment between inventory sites. 

3. Generate the following transaction and print a 1010, save 
the 1010, and print and save the 1010: 

• Return material to a warehouse (COE and non-COE 
material) 

• Return material to an outside vendor (COE and non- 
COE material) 

4. Verify all forms are handled properly 

5. A more detailed test case will be provided when it is 
determined how the feature will be programmed. 
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Attachments: 

(copies of screens, reports, 1. NONE 

etc. before and after proposed 

change) 

Signatures of Agreement: 

(add additional rows if 

necessary) 

BAE: 

Lead Analyst: 
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BAE FUNCTIONAL REQUIREMENT DOCUMENT 



Table # 6575 



BAE Start Date: 
BAE Comp. Date: 
BAE Hours: 



June 14, 1997 
June 16, 1997 
2 Hours 



BAE Name: 
BAE Tele. No, 
LA Assigned: 



Carol A. Brechtel 
205-977-3611 



CMVC Component Name: 



MATMGMT 



Associated Defect/Feature No.: 



6575 



Target Release: 

(give target release this 
needs to be in) 



Target Release Date: 

2. 1 (give target release 

date for this 
enhancement) 



Priority: 

(provide priority from 
'feature priority' list - 
production^ through 
deferred_low) 



Production low 



Revision No.: 
Reason for Revision: 



Subject: 

(brief description of change) 



1 . Enhance the inventory scan to allow the user to sort the scan 
by Serial Number, when requesting a scan for serialized 
inventory. 
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Introduction: 

(description of what system 1 . Today the user can sort an inventory scan by 15 different 
currently does, what needs attributes, but Serial Number is not one of the sort options, 

to be changed, and why) The scan will display/print all assigned material first. 

Enhance the system to allow the user to sort an inventory 

scan by serial number. 



Solution: 

(describe what the system 1 . Add the attribute of Serial Number to the "SorFields" grid on 

will or should do and any the "Sort Inventory" window. 

general constraints or 

conditions that limit the 

solution) 



Change(s): 

(detailed description of 1 . Allow the user to sort inventory scans by serial number when 

change)-[add additional requesting a scan for serialized material, (ascending order) 

rows if multiple changes] 2. Allow the user to select Serial Number as a sort option. 

3 . If Serial Number is selected display/print in ascending order. 



Performance Requirements: 

(list any performance 1 . There should be no noticeable affect on performance, 

requirements associated 
with this change) 
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Dependencies: 

(list any defects or features 1 . NONE 
that this enhancement is 
dependent on) 

Benefits: 

(provide benefits in dollars, 1 . Make it easier for the user to determine the on hand quantity 

reduced headcount, time of cable on a reel. Today the system will print/display all 

savings, etc. for doing this assigned material first, therefore, the user needs to scan the 

work) full report to determine the total amount of cable on a reel. 

2. Easier to compare what is in the system to what is on the 
yard. 



Affected Components: (check) (check) 

Yes No 
RTOC Instructions X 
HELP X 
User Guides X 
Testing X 
Infra-structure X 
Management Reports X 
Database X 



Interfaces: 

(list any legacy or new 1 . NONE 

interface systems impacted 
by this change) 
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Work-around: 

(is there a temporary work 
around??) 

(describe work around in 
detail) 



(check) 
Yes 



(check) 
No 



X 



Risks: 

(list factors that impact, 
positive/negative, not doing 
this change) 



1 . Inventory adjustments may be made that are not necessary. 

2. Not user friendly when doing a physical inventory. 



Business Rules: 

(list any business rules or 
constraints that should apply) 



1 . If the user requests an inventory scan sorted by serial 

number, the scan should be sorted in ascending order using 
the serial number. 



Documentation Changes: 

(list affected documents 1 . 

requiring change) 2. 

3. 



Materials Management User Guide 
Functional Decomps 
Test Scenarios 
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Acceptance Criteria/Test Scenario: 

(list test scenarios required to 1 . Display the "Inventory Scan Search Criteria" window 
test change prior to user 2. Select the "Sort By" button 

acceptance) REQUIRED 3. Verify that "Serial Number" appears in the "SorField" grid 

on the "Sort Inventory" window 

4. Select Serial Number and verify that it moves over to the 
"Sort Order" grid 

5. Arrange the sort order options so that Serial Number is the 
first option 

6. Select OK 

7. Run the Inventory scan - verify that it sorted in Serial 
Number order. 

Attachments: 

(copies of screens, reports, 
etc. before and after proposed 
change) 

Signatures of Agreement: 

(add additional rows if 

necessary) 

BAE: 

Lead Analyst: 
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BAE FUNCTIONAL REQUIREMENT DOCUMENT 



Table # 6426 FS 



BAE Start Date: 
BAE Comp. Date: 
BAE Hours: 



05/31/1997 
06/01/1997 
4 



BAE Name: 
BAE Tele. No.: 
LA Assigned: 



Mark Seal 
205-977-3618 



CMVC Component Name: 



CHANGE MGMT 



Associated Defect/Feature No.: 



6426 



Target Release: 

(give target release this 
needs to be in) 



2.01 



Target Release Date: 

(give target release 
date for this 
enhancement) 



Priority: 

(provide priority from 
'feature priority' list - 
production_hi through 
deferred_low) 



PROD 
HI 



Revision No.: 
Reason for Revision: 



Subject: 

(brief description of change) 1 . SERVER PROCESS TO PROVIDE NOTIFICATIONS 
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Introduction: 

(description of what system 1 . CURRENTLY THERE IS NO NOTIFICATION TO THE 
currently does, what needs SUPERVISOR AS TO WHEN AND WHO REPORTS AN 

to be changed, and why) EXCEPTION CODE OR WHEN ADDED STEPS ARE 

REPORTED. 



Solution: 

(describe what the system 
will or should do and any 
general constraints or 
conditions that limit the 
solution) 



1 . THE SOLUTION IS TO WRITE A SERVER PROCESS TO 
RUN EACH NIGHT AND READ THE DATA BASE. 
COLLECT ANY ADDED STEP AND/OR EXCEPTION 
INFORMATION BY RES ID. USING THE RES ID GET 
THE SUPERVISOR'S EMAIL ADDRESS AND SEND THE 
DATA TO THAT ADDRESS. 



Change(s): 

(detailed description of 
change)-[add additional 
rows if multiple changes] 



CREATE A SERVER PROCESS THAT WILL RUN IN A 

BATCH MODE EACH NIGHT. THIS PROCESS WILL 
LOOK AT EACH WORK REPORT THAT WAS 
CREATED OR CHANGED FOR EACH DAY. THE 
PROCESSED IND SHOULD BE SET TO "BA". THIS 
PROCESS SHOULD CHECK EACH WORK REPORT 
WITH A PROCESSEDJND SET TO "BA" TO SEE IF 
ANY ADDED STEPS HAVE BEEN REPORTED. IF 
SO THEN CAPTURE THE INFORMATION AS 
FOLLOWS. EMPLOYEE NAME, RES ID, DATE 
UNDER REPORT, ADDED STEP NUMBER AND 
REQUIRED REMARKS. 

THIS SERVER PROCESS WILL LOOK AT EACH NON-SS 
TIME REPORT THAT HAS A DATE AND TIME 
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STAMP FOR THE DAY BEING PROCESSED. IF A 
NON SS TIME REPORT DOES EXIST FOR THE 
PROCESSED DAY THEN CAPTURE THE 
INFORMATION AS FOLLOWS: EMPLOYEE NAME, 
RES ID, DATE UNDER REPORT, EXCEPTION CODE, 
START TIME, END TIME. 
USING THE EMPLOYEE'S RES ID, GO TO THE SUPER_RG 
FOR THE RES ID AND GET THE SUPERVISOR'S 
CUE) AND THEN GO TO THE EMPLOYEE AND GET 
THE SUPERVISOR'S EMAIL ADDRESS. ONCE THE 
EMAIL ADDRESS IS OBTAINED THEN SEND ALL 
OF THE CAPTURED DATA TO THE ADDRESS IN 
ONE E-MAIL MESSAGE. IF NO E-MAIL ADDRESS 
EXISTS THEN DON'T SEND THE INFORMATION 
TO ANY ONE. 

Performance Requirements: 

(list any performance 1 . THIS WILL BE DONE IN A BATCH MODE AND 

requirements associated SHOULD NOT AFFECT PERFORMANCE, 

with this change) 

Dependencies: 

(list any defects or features 1 . NONE 
that this enhancement is 
dependent on) 

Benefits: 

(provide benefits in dollars, THIS PROCESS WILL REPLACE THE CONTROLS THAT A 
reduced headcount, time SUPERVISOR MUST SIGN A WORK REPORT FOR 

savings, etc. for doing this EACH EMPLOYEE FOR EACH WORK DAY. 

work) BY NOTIFIYING THE SUPERVISOR OF ANY EXCEPTIONS 
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AND ADDED STEPS, APPROPRIATE ACTION CAN BE 
TAKEN IF NEEDED. THIS ALONG WITH THE 
CURRENT MTR REPORTS ARE CONSIDERED TO BE 
ACCEPCONTROLS. 



Affected Components: (check) (check) 

Yes No 

RTOC Instructions X 

HELP X 

User Guides X 

Testing X 

Infra-structure X 

Management Reports X 

Database X 



Interfaces: 

(list any legacy or new 1. NONE, 

interface systems impacted 
by this change) 

Work-around: (check) 

Yes 

(is there a temporary work X 
around??) 

(describe work around in 1. THE ONLY WORK AROUND IS FOR 
detail) THE SUPERVISOR TO 

PHYSICALLY LOG IN AND PULL 
UP EACH EMPLOYEE'S WORK 
REPORT AND ACCESS THE 
EXCEPTIONS SCREEN TO CHECK 
FOR EXCEPTIONS. THEN THE 



(check) 
No 
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SUPERVISOR WILL ACCESS THE 
WORK REPORT SCREEN AND 
CHECK FOR ANY ADDED STEPS. 
THIS WILL BE A VERY TIME 
CONSUMING PROCESS. 



Risks: 

(list factors that impact, 1 . WITHOUT PROPER CONTROLS A PAPER WORK 
positive/negative, not doing REPORT MAY BE NECESSARY TO OBTAIN A 

this change) SUPERVISOR' S SIGNATURE FOR APPROVAL. 



Business Rules: 

(list any business rules or 
constraints that should 
apply) 

ADD M&P TO RECOMMEND THAT ALL SUPERVISORS 
ENTER A VALID E-MAIL ADDRESS ON THE 
EMPLOYEE RECORDS. 



Document Changes: 

(list affected documents 1 . 
requiring change) 



Acceptance Criteria/Test Scenario: 

(list test scenarios required 1 . CREATE A WORK REPORT WHICH CONTAINS 
to test change prior to user OVERTIME AND SAVE A BALANCE THE REPORT, 

acceptance) REQUIRED RUN THE SERVER PROCESS. THE EXPECTED 

RESULT IS THAT THE SUPERVISOR OF THE 
EMPLOYEE ON THE WORK REPORT WILL RECEIVE 
AN E-MAIL WITH THE APPROPRIATE 
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INFORMATION. 

2 . CREATE A WORK REPORT WHICH CONTAINS AN 
ADDED STEP, SAVE AND BALANCE THE WORK 
REPORT. RUN THE SERVER PROCESS. THE 
EXPECTED RESULT IS THAT THE SUPERVISOR OF 
THE EMPLOYEE ON THE WORK REPORT WILL 
RECEIVE AN E-MAIL WITH THE APPROPRIATE 
INFORMATION. 

3. CREATE A WORK REPORT WHICH CONTAINS NO 
EXCEPTIONS OR ADDED STEPS AND SAVE AND 
BALANCE. RUN THE SERVER PROCESS. THE 
EXPECTED RESULT IS THAT THE SUPERVISOR OF 
THE EMPLOYEE ON THE WORK REPORT WILL NOT 
RECEIVE AN E-MAIL. 

4. ACCESS THE WORK REPORT IN NUMBER THREE 
AVOVE AND ADD OVERTIME AND AN ADDED 
STEP. SAVE AND CLOSE. RUN THE SERVER 
PROCESS. THE EXPECTED RESULT IS THAT THE 
SUPERVISOR OF THE EMPLOYEE ON THE WORK 
REPORT WILL RECEIVE AN E-MAIL WITH THE 
APPROPRIATE INFORMATION. 

Attachments: 

(copies of screens, reports, 1 . NONE 
etc. before and after 
proposed change) 

Signatures of Agreement: 

(add additional rows if necessary) 
BAE: 

Lead Analyst: 
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BAE FUNCTIONAL REQUIREMENT DOCUMENT 



Table # 6814A 



BAE Start Date: October 9, 1 997 

BAE Comp. Date: October 9, 1997 
BAE Hours: 2 V 2 hours 



BAE Name: Carol Brechtel 

BAE Tele, No.: 205-977-3611 
LA Assigned: 



CMVC Component Name: 



MATMGMT 



Associated Defect/Feature No,: 



NONE 



Target Release: 
(give target release this 
needs to be in) [Only 
identify if this is required 
for an emergency release 
or must be worked in next 
scheduled release] 



Target Release Date: 

(give target release 
date for this 
enhancement, if 
required) 



Priority: 

(provide priority from Top 25 Rating=l 5 

'feature priority' list - Module Rating=7 

number preliminary 
assigned by SME) 

Revision No.: (B, C, etc. - this will require new signatures) 

Reason for Revision: 
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1 . The purpose of this document is to provide the customer's 
view of the functionality that needs to be changed or added to 
the existing OSPCM product. It is not the detail design 
requirements. It should concentrate on the 'what' that is 
needed and not on the 'how' it is provided. 

2. All features that are > 40 hours/ 1 business area require a structured 
inspection walk through process (currently using FAGAN). This is 
to be scheduled by the responsible SME for this feature with the 
testing team lead, documentation team lead and the IT development 
Managers. The IT develop managers will assign the appropriate 
representatives to attend the meeting. These inspections are not to . 
inspect the author, they are to be used to understand the 
functionality required for development of the 'Detail Design 
Document 5 . 

3. The 'Analysis Phase Specific' checklist must be used, 
documented and baselined for each feature. 

4. Any correspondence associated with this feature should also 
be documented (i.e., impromptu meetings, phone 
conversations, etc.) and associated with the feature number. 
It should include time, date and participants. 

5. Continue numbering scheme in your text input under each to 
provide traceability for matrixes. 

1. Abstract: 

(brief description of 1.1 Add one additional display field to the Transaction Details 
change/addition) - This window, display the "Total on Hand Quantity" for the 

should pretty closely match material item on the transaction, this is for serialized and non 

the abstract in CMVC. serialized material. 

2. Current Problem: 
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General: 

(General Information - 
nothing is to be typed here, 
this is for information only 
about the functional spec 
process) 



(brief description of what 
system currently does, what 
needs to be changed, and 
why) 



2.1 "Total On Hand Qty" is not displayed on the 
Transaction Details window - currently the system 
displays the Transaction Quantity and the Balance 
Quantity. 



3. Proposed Solution: 

(brief description of what 
the system will or should do 
and any general constraints 
or conditions that limit the 
solution) 



3.1 Add one field to the Transaction Details 
window - add "Total on Hand Quantity" to the 
Transaction Data section of the window. For non- 
serialized material & serialized material. 



4. Change/Addition(s): 

(detailed description of 
change/addition) 



4.1 Add one field to the Transaction Data Section 
of the Transaction Details window. 



5. Performance Requirements: 

(list any performance 5.1 There should be no noticeable affect on 

requirements associated performance. 

with this change) [Identify 

system response 

requirements that must be 

met for user acceptance] 

6. Dependencies: 

(list any defects or features 6.1 NONE 

that this enhancement is 
dependent on or that will be 
dependent on this feature) 
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7. Benefits: 

(provide benefits in dollars, 
reduced headcount, time 
savings, etc. for doing this 
work) [This is required to 
identify any savings that 
can be attributed this 
feature for securing 
budget approval] 

8. Affected Components: 

RTOC Instructions 
HELP 
User Guides 
Testing 

Infra-structure 
Management Reports 
Database 

9. Interfaces: 

(list any legacy or new 
interface systems impacted 
by this change) [Make sure 
other interface systems are 
aware of and agree with 
any requirement change 
that impacts them before 
proceeding] 



7. 1 For two sided transactions the user would be 
required to add the Balance quantity from both 
sides of the transaction to determine the total 
quantity of material on hand. 

7.2 The Total on Hand Quantity would be 
display. 



(check) (check) 
Yes No 

X 

X 

X 
X 

X 
X 



9.1 NONE 



Exh. 2 - Page 65 



10. Work-around: 

(is there a temporary work 
around?) 

(describe work around in 
detail) [Also identify this in 
the OSPCM 'known 
problem' document] 

11. Risks: 

(list factors that impact, 
positive/negative, not doing 
this change) 

12. Business Rules: 

(list any business rules or 
constraints that should apply. 
If business rules are included 
in the changes section, 
identify these with asterisk in 
bold, ***business rule***) 

13. Documentation Changes: 
(list affected documents 
requiring change) 
[Documentation should 
prepare a checklist covering 
each document that must be 
updated for this feature] 



(check) (check) 
Yes No 

X 



10.1 Manually calculate the 
on hand quantity of the 
inventory item 



11.1 The user may believe they have more or less material 
inventory then they actually have. 



12.1 NONE 



13.1 User Guide 

13.2 Help 

13.3 Functional Decomps 
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14. Special Training/Implementation Requirements: 

(list any special 14.1 NONE 

training/implementation 

required for this feature. 

Identify what will be 

required to train and 

implement this feature to the 

customer, i.e., by 

documentation, e-mail, help, 

cue cards, on sight training, 

etc.) 



15. Acceptance Criteria/Test 

(list test scenarios required to 
test change prior to user 
acceptance, this can be 
updated after the detailed 
design is completed.) 
REQUIRED [Tester 
should prepare checklist 
based on these test 
scenarios for 

documentation on results of 
tests. These should be in 
matrix form identified back 
to the numbering scheme 
used in these test scenarios] 



Scenario: 

15.1 Use the "Show Inventory item" window to find inventory 
that has an unassigned and assigned balance. 

15.2 Either display the last transaction from here or go to Show 
Transactions 

15.3 Display transaction (from the Inventory item on Show 
Inventory item window) 

15.4 Display the details of the transaction 

15.5 Verify that they "Total on Hand Quantity" is displayed 

15.6 Return to the Show Inventory item window and verify the 
"Total on Hand quantity" displayed on the transaction was 
correct. 
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16. Attachments: 

(copies of screens, reports, 
etc. before and after proposed 
change-only identify if the 
customer requires the screen 
or something on the screen to 
look a certain way) 

Signatures of Agreement: 

(add additional rows if necessary) 
BAE: 

Lead Analyst: 
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BAE FUNCTIONAL REQUIREMENT DOCUMENT 



Table # 7055A 



BAE Start Date: 
BAE Comp. Date: 
BAE Hours: 



09/17/1997 
09/25/1997 
18 



BAE Name: 
BAE Tele, No.: 
LA Assigned: 



Larry Edgar 
977-7375 



CMVC Component Name: 



Change_mgmt 



Associated Defect/Feature No.: 



Target Release: 
(give target release this 
needs to be in) [Only 
identify if this is required 
for an emergency release 
or must be worked in next 
scheduled release] 



Target Release Date: 

(give target release 
date for this 
enhancement, if 
required) 



Priority: 

(provide priority from 
'feature priority' list - 
number preliminary 
assigned by SME) 



Prod hi 



Revision No.: 
Reason for Revision: 



(B, C, etc. - this will require new signatures) 
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1 . The purpose of this document is to provide the customer's 
view of the functionality that needs to be changed or added to 
the existing OSPCM product. It is not the detail design 
requirements. It should concentrate on the 'what' that is 
needed and not on the 'how' it is provided. 

2. All features that are > 40 hours/ 1 business area require a structured 
inspection walk through process (currently using FAGAN). This is 
to be scheduled by the responsible SME for this feature with the 
testing team lead, documentation team lead and the IT development 
Managers. The IT develop managers will assign the appropriate 
representatives to attend the meeting. These inspections are not to 
inspect the author, they are to be used to understand the 
functionality required for development of the 'Detail Design 
Document'. 

3. The 'Analysis Phase Specific' checklist must be used, 
documented and baselined for each feature. 

4. Any correspondence associated with this feature should also 
be documented (i.e., impromptu meetings, phone 
conversations, etc.) and associated with the feature number. 
It should include time, date and participants. 

5. Continue numbering scheme in your text input under each to 
provide traceability for matrixes. 

1. Abstract: 

(brief description of 1.1 Provide a system method to either advise user by display 
change/addition) - This message or to automatically point a production user to the 

should pretty closely match correct server when logging on to a unit that has not been 

the abstract in CMVC. used before for OSPCM. 

2. Current Problem: 



General: 

(General Information - 
nothing is to be typed here, 
this is for information only 
about the functional spec 
process) 
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(brief description of what 
system currently does, what 
needs to be changed, and 
why) 



2.1 Users download a new release in production 
on a unit not used for OSPCM before and do not 
verify the state server is pointed to. Can cause 
time outs and delays due to "traffic" routing. A 
default state of FL is given. 



3. Proposed Solution: 

(brief description of what 
the system will or should do 
and any general constraints 
or conditions that limit the 
solution) 



3 . 1 Provide an OSPCM method in or after the 
download process that will identify the user 
"correct server" based on location feedback. Then 
advise the user by display message dialog box to 
point to correct server if needed. 

3.2 Consider an automatic method to do the 
pointing during the download if not too complex. 



4. Change/Addition(s): 

(detailed description of 4.1 Add user location detection method to system 

change/addition) 4.2 Add method to determine correct server based 

on location detection 



4.3 Add method to display advisory message 
"please select state and choose State" on OSPCM 
Guide (may consider adding to the 
Production/Training selection). 

4.4 Consider if user can be pointed automatically 
during a download. 
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5. Performance Requirements: 

(list any performance 
requirements associated 
with this change) [Identify 
system response 
requirements that must be 
met for user acceptance] 

6. Dependencies: 

(list any defects or features 
that this enhancement is 
dependent on or that will be 
dependent on this feature) 

7. Benefits: 

(provide benefits in dollars, 
reduced headcount, time 
savings, etc. for doing this 
work) [This is required to 
identify any savings that 
can be attributed this 
feature for securing 
budget approval] 



5.1 No delay foreseen-should enhance user times. 



6.1 None. 



7.1 Will avoid the "traffic" routing congestion and 
thus reduce user time outs. User acceptance 
enhanced. 
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8. Affected Components: 



(check) 
Yes 



(check) 
No 



RTOC Instructions X 

HELP X 

User Guides X 

Testing X 

Infra-structure X 

Management Reports X 
Database X 

9. Interfaces: 

(list any legacy or new 9. 1 NONE 



interface systems impacted 
by this change) [Make sure 
other interface systems are 
aware of and agree with 
any requirement change 
that impacts them before 
proceeding] 
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10, Work-around: (check) (check) 

Yes No 

(is there a temporary work X 
around?) 

(describe work around in 10.1 Users have been and are continued 

detail) [Also identify this in to be advised during deployment 

the OSPCM 'known that a standard procedure is to 

problem' document] always (not just for OSPCM firsts) 

go to OSPCM Guide to select the 
State and choose/verify the local 
state. 



11. Risks: 

(list factors that impact, 1 1 . 1 Users complain of time outs as caused by routing traffic 
positive/negative, not doing which bogs down a server since use is not correctly 

this change) dispersed. 



12. Business Rules: 

(list any business rules or 12.1 Advise users to perform state verify function to avoid 

constraints that should apply. potential traffic delays 

If business rules are included 

in the changes section, 

identify these with asterisk in 

bold, ***business rule***) 

13. Documentation Changes: 

(list affected documents 13.1 Chapter to Overview of OSPCM Application, each 

requiring change) module - intro chapter and Getting Started user guide 



Exh. 2 - Page 75 



[Documentation should needs to reflect the added download message and manual 

prepare a checklist covering state selection procedure emphasis, 

each document that must be 
updated for this feature] 

14. Special Training/Implementation Requirements: 

(list any special 14.1 Deployment teams and/or training needs to continue to 

training/implementation emphasize the probability of delays and cause. 

required for this feature. 

Identify what will be required 

to train and implement this 

feature to the customer, i.e., 

by documentation, e-mail, 

help, cue cards, on sight 

training, etc.) 



15. Acceptance Criteria/Test Scenario: 

(list test scenarios required to 15.1 Perform a new release download in production and verify 

that a display message appears to advise user to select 
state after security logon. 

15.2 Go to a second test unit in production and select the state 
point option, then perform the new release download and 
determine if no message displayed. 

15.3 Use the OSPCM in the file to verify server changes. 



test change prior to user 
acceptance, this can be 
updated after the detailed 
design is completed.) 
REQUIRED [Tester should 
prepare checklist based on 
these test scenarios for 
documentation on results of 
tests. These should be in 
matrix form identified back 
to the numbering scheme 
used in these test scenarios] 



Exh. 2 - Page 76 



16. Attachments: 

(copies of screens, reports, 16.1 NONE 
etc. before and after proposed 
change-only identify if the 
customer requires the screen 
or something on the screen to 
look a certain way) 

Signatures of Agreement: 

(add additional rows if necessary) 

BAE: Larry Edgar 

Lead Analyst: 
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BAE FUNCTIONAL REQUIREMENT DOCUMENT 



Table # 7166 



BAE Start Date: 
BAE Comp. Date: 
BAE Hours: 



01/30/1998 
01/30/1998 
1 



BAE Name: 
BAE Tele. No.: 
LA Assigned: 



Wesley White 
977-7436 . 



CMVC Component Name: 



MGMT REPORTS 



Associated Defect/Feature No.: 



Target Release: 
(give target release this 
needs to be in) [Only 
identify if this is required 
for an emergency release 
or must be worked in next 
scheduled release] 



Target Release Date: 

Emergency (give target release Emergency 
date for this 
enhancement, if 
required) 



Priority: 

(provide priority from 
'feature priority' list — 
number preliminary 
assigned by SME) 



Revision No.: 
Reason for Revision: 



(B, C, etc. - this will require new signatures) 
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General: 

(General Information - 
nothing is to be typed here, 
this is for information only 
about the functional spec 
process) 



1 . The purpose of this document is to provide the customer's 
view of the functionality that needs to be changed or added to 
the existing OSPCM product. It is not the detail design 
requirements. It should concentrate on the 'what' that is 
needed and not on the 'how' it is provided. 

2. All features that are > 40 hours/ 1 business area require a structured 
inspection walk through process (currently using FAGAN). This is 
to be scheduled by the responsible SME for this feature with the 
testing team lead, documentation team lead and the IT development 
Managers. The IT develop managers will assign the appropriate 
representatives to attend the meeting. These inspections are not to 
inspect the author, they are to be used to understand the 
functionality required for development of the 'Detail Design 
Document'. 

3. The 'Analysis Phase Specific' checklist must be used, 
documented and baselined for each feature. 

4. Any correspondence associated with this feature should also 
be documented (i.e., impromptu meetings, phone 
conversations, etc.) and associated with the feature number. 
It should include time, date and participants. 

5. Continue numbering scheme in your text input under each to 
provide traceability for matrixes. 



1. Abstract: 

(brief description of 1.1 Create extract file from die material tracking report to bufit to 

change/addition) - This 90.11 .244. 1 72/bto/sys/lec3/ospcm 

should pretty closely match 
the abstract in CMVC. 
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2. Current Problem: 

(brief description of what 
system currently does, what 
needs to be changed, and 
why) 

3. Proposed Solution: 

(brief description of what 
the system will or should do 
and any general constraints 
or conditions that limit the 
solution) 

4. Change/ Addition(s): 

(detailed description of 
change/addition) 



2.1 Extract files needed for SSI business process 
server to load data into LEC3 database 



3.1 Extract fields from DLC material Tracking 
report and bufit to ip address nightly. Email 
verification that process did or did not run to 
Paul.W.White@bridge.bellsouth.com 



4.1 Run DLC Material Tracking Report Nightly 
and Extract: 

4.2 Wire, Center charl 7 

4.3 Design, Engineer char35 

4.4 Job, Number charl 6 

4.5 Prtchar6 

4.6 Stepchar9 

4.7 Work, id char 12 

4.8 GLCcharl6 

4.9 FRCcharl4 

4.10 Work, action char 16 

4.11 Statchar6 

4.12 Substep, Stat Date char20 

4.13 Material, Desc char30 

4.14 Order, Quantity char21 

4.15 Mtl, Stat char 12 

4.16 Mtl, Stat date char 16 
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4.17 Capri P0# char 15 
4.18 

4.19 Bufitfileto 

90. 1 1 .244. 1 72/bto/sys/lec3/ospcm 

4.20 

4.21 file should be called ospcm with an 
extension of the date yyyy/mm/dd example: 
ospcm.19980130 
4.22 

4.23 File should contain data for all states 
FL, GA, SC, NC, TN, KY, LA, AL, MS 
4.24 

4.25 The new DLC Tracking Report edits should 
be put into production before this report is run. 
4.26 



4.27 The report should bufit the files MON-FRI at 

10:00 PM EST 

4.28 

4.29 

5. Performance Requirements: 

(list any performance 5.1 No deterioration in current response time. 

requirements associated 

with this change) [Identify 

system response 

requirements that must be 

met for user acceptance] 
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6. Dependencies: 

(list any defects or features 6. 1 NONE 
that this enhancement is 
dependent on or that will be 
dependent on this feature) 

7. Benefits: 

(provide benefits in dollars, 7.1 NONE 

reduced headcount, time 

savings, etc. for doing this 

work) [This is required to 

identify any savings that 

can be attributed to this 

feature for securing 

budget approval] 

8- Affected Components: (check) (check) 



Yes 



No 



RTOC Instructions 



HELP 



User Guides 



Testing 



X 



Infra-structure 



Management Reports 



Database 



9. Interfaces: 



(list any legacy or new 
interface systems impacted 
by this change) [Make sure 



9.1 NONE 
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other interface systems are 
aware of and agree with 
any requirement change 
that impacts them before 
proceeding] 



10. Work-around: 



(check) 



(check) 



Yes 



No 



(is there a temporary work 



X 



around?) 

(describe work around in 
detail) [Also identify this in 
the OSPCM 'known 
problem' document] 

11. Risks: 

(list factors that impact, 
positive/negative, not doing 
this change) 

12. Business Rules: 

(list any business rules or 
constraints that should apply. 
If business rules are included 
in the changes section, 
identify these with asterisk in 
bold, ***business rule***) 

13. Documentation Changes: 

(list affected documents 13.1 NONE 

requiring change) 

[Documentation should 

prepare a checklist covering 

each document that must be 

updated for this feature] 
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14. Special Training/Implementation Requirements: 

(list any special 14.1 NONE 

training/implementation 

required for this feature. 

Identify what will be 

required to train and 

implement this feature to the 

customer, i.e., by 

documentation, e-mail, help, 

cue cards, on sight training, 

etc.) 

15. Acceptance Criteria/Test Scenario: 

(list test scenarios required to 15.1 NONE 

test change prior to user 

acceptance, this can be 

updated after the detailed 

design is completed.) 

REQUIRED [Tester 

should prepare checklist 

based on these test 

scenarios for 

documentation on results of 
tests. These should be in 
matrix form identified back 
to the numbering scheme 
used in these test scenarios] 
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16. Attachments: 

(copies of screens, reports, 16.1 NONE 
etc. before and after proposed 
change-only identify if the 
customer requires the screen 
or something on the screen to 
look a certain way) 

Signatures of Agreement: 

(add additional rows if necessary) 
BAE: 

Lead Analyst: 
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BAE FUNCTIONAL REQUIREMENT DOCUMENT 



Table # 7349A 



BAE Start Date: 



11/19/1997 



BAE Name: 



Larry Edgar 



BAE Comp. Date: 



12/12/1997 



BAE Tele. No.: 



205-977-7375 



BAE Hours: 



LA Assigned: 



CMVC Component Name: 



Change_mgmt 



Associated Defect/Feature No.: 



N/A 



Target Release: 

(give target release this 
needs to be in) [Only 



Target Release Date: 

(give target release date for 
this enhancement, if required) 



1/1/1998 



identify if this is required 
for an emergency release 
or must be worked in next 
scheduled release] 

Priority: 

(provide priority from 
'feature priority' list - 
number preliminary 
assigned by SME 

Revision No.: (B, C, etc. - this will require new signatures) 

Reason for Revision: 
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General: 

(General Information - 
nothing is to be typed here, 
this is for information only 
about the functional spec 
process) 



1 . The purpose of this document is to provide the customer's 
view of the functionality that needs to be changed or added to 
the existing OSPCM product. It is not the detail design 
requirements. It should concentrate on the 'what' that is 
needed and not on the 'how' it is provided. 

2. All features that are > 40 hours/ 1 business area require a structured 
inspection walk through process (currently using FAGAN). This is 
to be scheduled by the responsible SME for this feature with the 
testing team lead, documentation team lead and the IT development 
Managers. The IT develop managers will assign the appropriate 
representatives to attend the meeting. These inspections are not to 
inspect the author, they are to be used to understand the 
functionality required for development of the 'Detail Design 
Document'. 

3. The 'Analysis Phase Specific' checklist must be used, 
documented and baselined for each feature. 

4. Any correspondence associated with this feature should also 
be documented (i.e., impromptu meetings, phone 
conversations, etc.) and associated with the feature number. 
It should include time, date and participants. 

5. Continue numbering scheme in your text input under each to 
provide traceability for matrixes. 



1. Abstract: 

(brief description of 1.1 Prepare/provide a search program to find all occurrences of 
change/addition) - This the T, D, and F prefix FRCs in Florida CMCs for open 

should pretty closely match EWOs. Then make global changes to change the prefixes 

the abstract in CMVC. from T, D, F to be '8'. Verify that FRCs from CORTS valid. 
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2. Current Problem: 

(brief description of what 
system currently does, what 
needs to be changed, and 
why) 



2.1 Florida uses the T, D, and F prefixed FRCs for 
fiber per the state PSC but this will change 
effective 1/1/98 so all substeps on open EWOs 
need to be found and changed per CCRs # 287, 
288 and 292. 



3. Proposed Solution: 

(brief description of what 
the system will or should do 
and any general constraints 
or conditions that limit the 
solution) 



3.1 Provide a program to find each occurrence of 
the T, D, and F prefixed FRCs in Florida CMCs 
and then make "global" changes to change the 
prefix to the number "8" for each cable substep 
and remove the TDF if circuit equipment. 



4. Change/Addition(s): 

(detailed description of 
change/addition) 



4.1 Find each T, D, and F prefix FRC in Florida 
EWOs. 

Change each occurrence by removing the letter 
prefix and/or substitute with an eight (8) as 
example: 

D/F/T 12C/X/Mwillbe812C/X/M 
D/F/T 22C/X/M will be 822C/X/M 
D/F/T 5C/X/M will be 85C/X/M 
D/F/T 45C/X/M will be 845C/X/M 
D/F/T 6C/X/M will be 86C/X/M 
D/F/T 52/C/X/M will be 852C/X/M 
D/F/T 257C/X/M will be 257C/X/M 
D/F 958C/X/M will be 958C/X/M 
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5. Performance Requirements: 

(list any performance 5.1 None since this should be done at night or weekend times. 

requirements associated with 

this change) [Identify 

system response 

requirements that must be 

met for user acceptance] 



6. Dependencies: 

(list any defects or features 6.1 NONE 
that this enhancement is 
dependent on or that will be 
dependent on this feature) 



7. Benefits: 

(provide benefits in dollars, 7.1 Avoid each CMC having to do manual and 

reduced headcount, time separate searches and manual changes, 

savings, etc. for doing this 
work) [This is required to 
identify any savings that 
can be attributed this 
feature for securing 
budget approval] 
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8. Affected Components: (check) (check) 

Yes No 
RTOC Instructions X 
HELP X 
User Guides X 
Testing X 
Infra-structure X 

Management Reports X 
Database X 

9. Interfaces: 

(list any legacy or new 9.1 NONE 



interface systems impacted 
by this change) [Make sure 
other interface systems are 
aware of and agree with 
any requirement change 
that impacts them before 
proceeding] 
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10. Work-around: 



(check) 
Yes 



(check) 
No 



(is there a temporary work X 
around?) 

(describe work around in 10.1 Each CMC in Florida will be required to 
detail) [Also identify this in search and find all occurrences of open 

the OSPCM 'known T, D, and F prefix FRCs. Then, each 

problem' document] such substep will require a manual 

change. Note that this must be done in a 
very short time frame since old codes 
are valid until 12/31/1997. 

11. Risks: 

(list factors that impact, 11.1 Probable errors in changes and reporting of FRCs. Much 

positive/negative, not doing manual work to accomplish task, 

this change) 

12. Business Rules: 

(list any business rules or 12.1 Refer to CCRs #287, 288 and 292 which specify the change. 

constraints that should This does not change what we do but does change the FRCs 

apply. If business rules are that are valid. 

included in the changes 

section, identify these with 

asterisk in bold, 

***business rule***) 
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13. Documentation Changes: 

(list affected documents 13.1 Verify that user guides and help do not contain reference to 

requiring change) FRCs such as Tnnx. 

[Documentation should 

prepare a checklist 

covering each document 

that must be updated for 

this feature] 

14. Special Training/Implementation Requirements: 

(list any special 14. 1 Notify Florida users in advance that this feature is pending 

training/implementation so they do not make effort to do. Consider using a 

required for this feature. broadcast message on the system. 

Identify what will be 

required to train and 

implement this feature to the 

customer, i.e., by 

documentation, e-mail, help, 

cue cards, on sight training, 

etc.) 

15. Acceptance Criteria/Test Scenario: 

(list test scenarios required to 15.1 Perform JE data creation to verify changed FRCs are OK. 
test change prior to user Open an EWO that had prefix of T, D, and F to ascertain 

acceptance, this can be change, 
updated after the detailed 
design is completed.) 
REQUIRED [Tester 
should prepare checklist 
based on these test 
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scenarios for 

documentation on results of 
tests. These should be in 
matrix form identified back 
to the numbering scheme 
used in these test scenarios] 

16. Attachments: 

(copies of screens, reports, 16.1 NONE 
etc. before and after proposed 
change-only identify if the 
customer requires the screen 
or something on the screen to 
look a certain way) 

Signatures of Agreement: L.A. Edgar 

(add additional rows if 

necessary) 

BAE: 

Lead Analyst: 
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BAE FUNCTIONAL REQUIREMENT DOCUMENT 



Table # 7916c 



BAE Start Date: 



04/07/1998 



BAE Name: 



Mark Seal 



BAE Comp. Date: 



06/19/1998 



BAE Tele. No.: 



205-977-3618 



BAE Hours: 



LA Assigned: 



CMVC Component Name: 



Billing and Reporting 



Associated Defect/Feature No.: 



Target Release: 

(give target release this 
needs to be in) [Only 



2.15 



Target Release Date: 

(give target release date for 
this enhancement, if required) 



identify if this is required 
for an emergency release 
or must be worked in next 
scheduled release] 

Priority: 

(provide priority from 1 9 

'feature priority' list - 
number preliminary 
assigned by SME) 

Revision No.: (B, C, etc. - this will require new signatures) 
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Reason for Revision: B. The contract material correction screen in Billing and 

Reporting must have more changes. The correction process 
behind the Bulk reporting screen must recognize disbursed 
and non-disbursed material. 
C. The contract material requires more information than is 
presently contained on the Bulk screens. It has been 
decided to use the material corrections screen in Billing and 
Reporting. This revision addresses the changes to that 
screen in order to make material corrections on contractor 
completed substeps. 



General: 

(General Information - 
nothing is to be typed here, 
this is for information only 
about the functional spec 
process) 

inspection walk through process (currently using FAG AN). This is 
to be scheduled by the responsible SME for this feature with the 
testing team lead, documentation team lead and the IT development 
Managers. The IT develop managers will assign the appropriate 
representatives to attend the meeting. These inspections are not to 
inspect the author, they are to be used to understand the 
functionality required for development of the 'Detail Design 
Document'. 

3. The 'Analysis Phase Specific' checklist must be used, 
documented and baselined for each feature. 

4. Any correspondence associated with this feature should also 
be documented (i.e., impromptu meetings, phone 
conversations, etc.) and associated with the feature number. 
It should include time, date and participants. 



1 . The purpose of this document is to provide the customer's 
view of the functionality that needs to be changed or added to 
the existing OSPCM product. It is not the detail design 
requirements. It should concentrate on the 'what' that is 
needed and not on the 'how' it is provided. 

2. All features that are > 40 hours/1 business area require a structured 
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5. Continue numbering scheme in your text input under each to 
provide traceability for matrixes. 



1. Abstract: 

(brief description of 
change/addition) - This 
should pretty closely match 
the abstract in CMVC. 



1 . 1 Allow telco users to change material on completed contractor 
substeps in Billing and Reporting. 

1.2 Do not allow material to be disbursed when errors are 
returned from the material edit process. 

1 .3 Material error messages from the material edit process are 
not clear enough for the user to know how to make 
corrections. 



2. Current Problem: 

(brief description of what 2. 1 Cannot correct or change any materials 

system currently does, what reporting on a contractor substep. 

needs to be changed, and 2.2 All material is being disbursed when the 

why) substep is completed even if errors are returned 

from the material management process. 

2.3 Material error messages from the material edit 

process are not clear enough for the user to know 

how to make corrections. 
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3. Proposed Solution: 

(brief description of what 
the system will or should do 
and any general constraints 
or conditions that limit the 
solution) 



3.1 Allow a telco user to change material on a 
contractor substep on the material corrections 
screen in Billing and Reporting module. 

3.2 Do not disburse material to FP on contract 
substeps when an error is generated in the material 
management process. Create material usage 
records and reversals the same way workstation 
handles materials. 

3.3 Where possible change the error messages 
being provided from the material edit process to 
provide more information so users can understand 
the problems and make corrections. 



4. Change/Addition(s): 

(detailed description of 
change/addition) 



4.1 Changes 

Change the system so that when a contractor 
substep is completed in Billing and Reporting that 
the system will generate a material usage record. 
Change the logic so that when a contractor substep 
is completed that the system does not 
automatically set the opeds indicator to "Y". This 
indicator should be set only if no error is returned 
from the material management process. If a 
negative return code is generated in the material 
management process then the error should be 
displayed on the "Error Correction" screen in 
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Billing and Reporting. 

Change the material corrections screen in Billing 
and Reporting so that a user can access any 
contractor completed substep's material 
information that is in error. 
Allow the user to edit the material information and 
save. If the material correction passes the material 
edit process then set the opeds indicator to "Y". 
The user should be able to change the same fields 
that are currently being edited in workstation. 
Allow the user to enter a job name and access 
material for editing purposes on jobs that do not 
have a material management processing error. 
After the user makes changes the system will 
check the material management process for 
negative return codes. If no errors are found then 
the system will create a reversal usage record and 
a new material usage record to go to FP. 

5. Performance Requirements: 

(list any performance 5.1 These changes should not affect the performance of the 

requirements associated Billing and Reporting process at all. 

with this change) [Identify 

system response 

requirements that must be 

met for user acceptance] 
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6. Dependencies: 

(list any defects or features 6.1 NONE 
that this enhancement is 
dependent on or that will be 
dependent on this feature) 



Exh. 2 -Page 100 



7. Benefits: 

(provide benefits in dollars, 
reduced headcount, time 
savings, etc. for doing this 
work) [This is required to 
identify any savings that 
can be attributed this 
feature for securing 
budget approval] 

8. Affected Components: 

RTOC Instructions 
HELP 
User Guides 
Testing 

Infra-structure 
Management Reports 
Database 

9. Interfaces: 

(list any legacy or new 
interface systems impacted 
by this change) [Make sure 
other interface systems are 
aware of and agree with 
any requirement change 
that impacts them before 
proceeding] 



7.1 Telco users will be able to correct material 
reporting errors for contract substeps. 

7.2 This will also stop material from being 
disbursed to FP when errors occur in the material 
management process. 



X 



(check) (check) 
Yes No 

X 



X 
X 



X 
X 



X 



9.1 OSPCM Financial Process interface will send 
corrected material reporting information on 
contract substeps as well as telco substeps. This 
process should not be affected by the changes in 
this specification. 
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10. Work-around: 

(is there a temporary work 
around?) 

(describe work around in 
detail) [Also identify this in 
the OSPCM 'known 
problem' document] 



(check) 
Yes 



10.2 Currently there is no way to correct 
material errors generated in OPSCM or 
FP for completed contract substeps. 



(check) 
No 



11. Risks: 

(list factors that impact, 11.1 If this change is not made then there is no 

positive/negative, not doing way in OSPCM to correct material reporting 

this change) errors generated in OPSCM or FP for contract 

completed substeps. 



12. Business Rules: 

(list any business rules or 
constraints that should apply. 
If business rules are included 
in the changes section, 
identify these with asterisk in 
bold, ***business rule***) 



12.1 



Do not allow any users or the system to 
uncomplete a contractor substep. 
Any change in material on a completed contract 
substep will not uncomplete the substep. 
Do not change or delete an invoice or CIBE if 
one exists for a completed contract substep. 
When an invoice is created for a completed 
contract substep that has had the material 
changed, then the invoice will continue to be 
based on the cwi and cwi quantity. 
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This process will NOT change the substep flag 
from C (contract) to T (telco). 



13. Documentation Changes: 

(list affected documents 13.1 Billing and Reporting user guides and help 

requiring change) create or update any job aid on material 

[Documentation should corrections, 
prepare a checklist covering 
each document that must be 
updated for this feature] 

14. Special Training/Implementation Requirements: 

(list any special 14.1 Some training may be required for the 

training/implementation material correction screen's new functionality. 

required for this feature. 

Identify what will be required 

to train and implement this 

feature to the customer, i.e., 

by documentation, e-mail, 

help, cue cards, on sight 

training, etc.) 



15. Acceptance Criteria/Test Scenario: 

(list test scenarios required to 
test change prior to user 
acceptance. This can be 
updated after the detailed 
design is completed) 
REQUIRED [Tester should 



15.1 Billing and Reporting: 
Complete a contract substep in Billing and 
Reporting that has no errors from the material 
process. Check the Opeds Ind. And it should be 
set to "Y". 

Verify that the material information is sent to FP. 
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prepare checklist based on 
these test scenarios for 
documentation on results of 
tests. These should be in 
matrix form identified back 
to the numbering scheme 
used in these test scenarios] 



Repeat this process where an invoice and/or 
CIBE is generated and verify that the material 
flows to FP in the same manner as above. 
15.2 Billing and Reporting: 
Complete a contract substep in Billing and 
Reporting that has errors returned from the 
material process. Check the Opeds Ind. and it 
should be set to "N." 

Check the material correction screen in Billing 
and Reporting and an error should be displayed. 
Verify that all fields can be edited and make the 
necessary corrections. 

Check the Opeds Ind. and it should be set to "Y " 
Verify that the material information is sent to FP. 
15.3 

Complete a contract substep in Billing and 
Reporting that has errors returned from the 
material process. Check the Opeds Inc. and it 
should be set to "N." 

Check the material correction screen in Billing 
and Reporting and an error should be displayed. 
Verify that all fields can be edited and make 
corrections that will generate another error. 
Verify that the system will not save this until the 
error is corrected. 

Check the Opeds Ind. and it should be set to "N". 
Make the correction and verify that the Opeds 
Ind. is set to "Y" and the material is disbursed to 
FP. 
15.4 
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Access the material correction screen in Billing 
and Reporting and enter a job name, print, and 
step. 

Report and enter a job name, print and step. 
Verify that changes can be made to existing 
material information even though there is no 
error. 

Verify that a reversal usage is created and a new 
material usage record is created and sent to FP. 

16. Attachments: 

(copies of screens, reports, 16.1 NONE 

etc. before and after proposed 

change-only identify if the 

customer requires the screen 

or something on the screen to 

look a certain way) 

Signatures of Agreement: 

(add additional rows if 

necessary) 

BAE: 

Lead Analyst: 
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BAE FUNCTIONAL REQUIREMENT DOCUMENT 



Table # 7900a 



BAE Start Date: 04/08/1 998 
BAE Comp. Date: 04/08/1998 
BAE Hours: 3 



BAE Name: Mark Seal 

BAE Tele. No.: 205-977-3618 
LA Assigned: 



CMVC Component Name: 
Associated Defect/Feature No.: 
Target Release: 

(give target release this 2.12 
needs to be in) [Only 
identify if this is required 
for an emergency release 
or must be worked in next 
scheduled release] 



Workstation 
7944 

Target Release Date: 

(give target release date for 
this enhancement, if required) 



Priority: 

(provide priority from 1 8 

'feature priority' list - 
number preliminary 
assigned by SME 
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Revision No.: 
Reason for Revision: 



(B, C, etc. - this will require new signatures) 



General: 

(General Information - 
nothing is to be typed here, 
this is for information only 
about the functional spec 
process) 



1 . The purpose of this document is to provide the customer's 
view of the functionality that needs to be changed or added to 
the existing OSPCM product. It is not the detail design 
requirements. It should concentrate on the 'what' that is 
needed and not on the 'how' it is provided. 

2. All features that are > 40 hours/1 business area require a structured 
inspection walk through process (currently using FAGAN). This is 
to be scheduled by the responsible SME for this feature with the 
testing team lead, documentation team lead and the IT development 
Managers. The IT develop managers will assign the appropriate 
representatives to attend the meeting. These inspections are not to 
inspect the author, they are to be used to understand the 
functionality required for development of the 'Detail Design 
Document'. 

3. The 'Analysis Phase Specific' checklist must be used, 
documented and baselined for each feature. 

4. Any correspondence associated with this feature should also 
be documented (i.e., impromptu meetings, phone 
conversations, etc.) and associated with the feature number. 
It should include time, date and participants. 

5. Continue numbering scheme in your text input under each to 
provide traceability for matrixes. 
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1. Abstract: 

(brief description of 1.1 Allow more users to access work reports and work report 

change/addition) - This errors generated by MTR. 

should pretty closely match 1 .2 Allow core staff users the ability to create work reports, 
the abstract in CMVC 



2. Current Problem: 

(brief description of what 
system currently does, what 
needs to be changed, and 
why) 



2.1 Currently, Core Staff, level 59 managers, craft 
and their supervisors can view errors and access 
existing work reports. This is limited for the 
supervisor to only those reports for employees 
assigned to them. 

2.2 Currently, only the craft and their supervisors 
can create work reports. 



3. Proposed Solution: 

(brief description of what 
the system will or should do 
and any general constraints 
or conditions that limit the 
solution) 



3.1 Change the workstation module to allow 
clerical users to have access to workstation and 
view MTR errors, MTR profiles and correct 
existing work reports. 



3.2 Change the workstation module so that core 
staff users will have the ability to create new work 
reports. NOTE: Level 59 manager access will not 
change due to this feature. 
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4. Change/Addition(s): 

(detailed description of 
change/addition) 



4. 1 Any user that is identified in the employee 
editor as non-management and has a work type of 



"Clerical" will have access to workstation and will 
be allowed to open the MTR error screen, the 
MTR profile screen and existing work reports for 
all employees in the CMC. For a clerical user 
disable all other tool bar buttons and "File" 
options. Currently, if a user has access to the 
MTR error screen then he/she can open existing 
work reports by double clicking on the error and 
there should be no change in that functionality. 
4.2 Change the system so that any user with a 
23 1 security tag (core staff user) will have the 
ability to create work reports. There will be no 
change for level 59 managers. 



5. Performance Requirements: 
(list any performance 
requirements associated 
with this change) [Identify 
system response 
requirements that must be 
met for user acceptance] 



5.1 The changes identified in this functional 
specification should not affect system 
performance. 



6. Dependencies: 

(list any defects or features 



6. 1 Defect 7944 must be worked with this 



that this enhancement is 



feature. 



dependent on or that will be 
dependent on this feature) 
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7. Benefits: 

(provide benefits in dollars, 7.1 Clerical users need access to all errors and 

reduced headcount, time existing work reports. Clerical users need access 

savings, etc. for doing this to the MTR profile for all employees in the CMC. 

work) [This is required to 7.2 Core staff users need to be able to create work 

identify any savings that reports for testing and investigating troubles, 

can be attributed this There will be no change for level 59 management 

feature for securing users, 
budget approval] 



8. Affected Components: (check) (check) 

Yes No 
RTOC Instructions X 
HELP X 
User Guides X 
Testing X 
Infra-structure X 

Management Reports X 
Database X 

9. Interfaces: 

(list any legacy or new 9.1 NONE 



interface systems impacted 
by this change) [Make sure 
other interface systems are 
aware of and agree with 
any requirement change 
that impacts them before 
proceeding] 
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10. Work-around: 



(check) 



(check) 



Yes 



No 



(is there a temporary work 



X 



around?) 

(describe work around in 
detail) [Also identify this in 
the OSPCM 'known 
problem' document] 

11. Risks: 

(list factors that impact, 11.1 The. only work around is to log onto the system using 
positive/negative, not doing someone else's cuid and password which is a security 

this change) violation. 



12. Business Rules: 

(list any business rules or 12.1 A core staff user should have access to read, create and 
constraints that should apply. update data. 

If business rules are included 12.2 A clerical user will not be allowed to create new work 
in the changes section, reports. 

identify these with asterisk in 12.3 A craft employee with a work type of "placing, splicing, 
bold, ***business rule***) mixed or I&M" should continue to have access to their 



MTR errors and work reports only. 
12.4 A Supervisor's access should not be changed due to this 



feature. 



12.5 A level 59 management user's access will not change due 



to this feature. 
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13. Documentation Changes: 

(list affected documents 13.1 Workstation user guides and help. 

requiring change) 

[Documentation should 

prepare a checklist covering 

each document that must be 

updated for this feature] 



14. Special Training/Implementation Requirements: 

(list any special 14.1 NONE 

training/implementation 

required for this feature. 

Identify what will be required 

to train and implement this 

feature to the customer, i.e., 

by documentation, e-mail, 

help, cue cards, on sight 

training, etc.) 



15. Acceptance Criteria/Test Scenario: 

(list test scenarios required to 

test change prior to user 

acceptance. This can be 

updated after the detailed 

design is completed) 

REQUIRED [Tester should 

prepare checklist based on 

these test scenarios for 

documentation on results of 

tests. These should be in 

matrix form identified back 



15.1 Level 59 Management user; 

Log in to OSPCM as a management user and 
access the MTR error screen. All errors for the 
CMC should be displayed. 
Double click on an error for an employee. 
The employee work report should open. 
Updates to the work report should be allowed 
along with save and save and close. 

15.2 Clerical user; 

Log in to OSPCM as a clerical user and access 
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to the numbering scheme 
used in these test scenarios] 



the MTR error screen. All errors for the CMC 
should be displayed. 

Double click on an error for any employee. 
The employee work report should open. 
Updates to the work report should be allowed 
along with save and save and close. 
Access the MTR profile screen and make 
changes to an employee's profile. 
Verify that as a clerical user a new work report 
cannot be created. 

15.3 Core staff user; 

Log in to OSPCM as a core staff users and 

access the MTR error screen. All errors for the 

CMC should be displayed. 

Double click on an error for an employee. 

The employee work report should open. 

Updates to the work report should be allowed 

along with save and save and close. 

From the workstation desk top, click on the 

NEW button on the tool bar. 

The employee drop down list should display 

with all employees for the CMC listed. 

Select one employee and build a work report and 

save and close. 

From the workstation desk top, click on the 

NEW button on the tool bar. 

The employee drop down list should display 

with all employees for the CMC listed. 

Select one employee and click OK. 

Add up to 5 additional employees and build a 
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work report and save and close. 

From the workstation desk top, click on FILE 

and select new report. 

The crew screen should display with all 

employees for the CMC listed. 

Select one employee and build a work report and 

save and close. 

From the workstation desk top, click on FILE 

and select new report. 

The crew screen should display with all 

employees for the CMC listed. 

Select up to 6 employees and build a work report 

and save and close. 

15.4 Supervisor 

Log in to OSPCM as a supervisor and access the 
MTR error screen. All errors for that supervisor 
should be displayed. 

Double click on an error for an employee. 

The employee work report should open. 

Updates to the work report should be allowed 

along with save and save and close. 

From the workstation desk top, click on the new 

button on the tool bar. 

The employee work report should open. 

Updates to the work report should be allowed 

along with save and save and close. 

From the workstation desk top, click on the 

NEW button on the tool bar. 

The employee drop down list should display 

with all employees for the supervisor only. 
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Select one employee and build a work report and 
save and close. 

From the workstation desk top, click on the 

NEW button on the tool bar. 

The employee drop down list should display 

with all employees for the Supervisor. 

Select one employee and click OK. 

Add up to 5 additional employees and build a 

work report and save and close. 

15.5 

Verify that superiors and craft employees access 

does not change with this feature. 

15.6 

Perform regression testing on supervisor and 
craft functionality. 

16. Attachments: 

(copies of screens, reports, 16.1 NONE 
etc. before and after proposed 
change-only identify if the 
customer requires the screen 
or something on the screen to 
look a certain way) 
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Signatures of Agreement: 

(add additional rows if necessary) 
BAE: 

Lead Analyst: 



BAE FUNCTIONAL REQUIREMENT DOCUMENT 



Table # 7903A 



BAE Start Date: 



May 1, 1998 



BAE Name: 



Carol A. Brechtel 



BAE Comp. Date: 



May 6, 1998 



BAE Tele. No.: 



205-977-3611 



BAE Hours: 



1.5 hours 



LA Assigned: 



Karin dinger 



CMVC Component Name: 



Materials Management 



Associated Defect/Feature No.: 



Target Release: 

(give target release this 
needs to be in) [Only 



Target Release Date: 

(give target release date for 
this enhancement, if required) 



identify if this is required 
for an emergency release 
or must be worked in next 
scheduled release] 

Priority: 

(provide priority from 
'feature priority' list - 
number preliminary 
assigned by SME 

Revision No.: (B, C, etc. - this will require new signatures) 

Reason for Revision: 
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General: 

(General Information - 
nothing is to be typed here, 
this is for information only 
about the functional spec 
process) 



1 . The purpose of this document is to provide the customer's 
view of the functionality that needs to be changed or added to 
the existing OSPCM product. It is not the detail design 
requirements. It should concentrate on the 'what' that is 
needed and not on the 'how' it is provided. 

2. All features that are > 40 hours/ 1 business area require a structured 
inspection walk through process (currently using FAG AN). This is 
to be scheduled by the responsible SME for this feature with the 
testing team lead, documentation team lead and the IT development 
Managers. The IT develop managers will assign the appropriate 
representatives to attend the meeting. These inspections are not to 
inspect the author, they are to be used to understand the 
functionality required for development of the 'Detail Design 
Document'. 

3. The 'Analysis Phase Specific' checklist must be used, 
documented and baselined for each feature. 

4. Any correspondence associated with this feature should also 
be documented (i.e., impromptu meetings, phone 
conversations, etc.) and associated with the feature number. 
It should include time, date and participants. 

5. Continue numbering scheme in your text input under each to 
provide traceability for matrixes. 
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1. Abstract: 

(brief description of 1.1 Add the age of the material to the "Inventory Scan 

change/addition) - This Summary" crystal report in Materials Management, 

should pretty closely match 
the abstract in CMVC. 



2. Current Problem: 

(brief description of what 
system currently does, what 
needs to be changed, and 
why) 



2.1 Today the 'Inventory Scan Summary' report 
displays/prints the MIC, material description, 
serial number, reel type, quantity, bin loc, 
inventory site, phy. Loc, job number, res id. And 
status of all material items displayed on the report. 
Today the filed user must display/print the 
'Inventory Scan Details' report to know the age of 
the material, this is a two line report and contains 
much more information then the Summary Report. 
Also the detail report is usually three times the size 
of the summary report when printed. 



3. Proposed Solution: 

(brief description of what 3 . 1 Enhance the ' Inventory Scan Summary' 

the system will or should do crystal report-add one additional column to 

and any general constraints display/print the AGE of the material, 
or conditions that limit the 
solution) 

4. Change/Addition(s): 

(detailed description of 4.1 Add one column to display the Age of material 

change/addition) on the 'Inventory Scan Summary' crystal report in 
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Materials Management. The column can be added 
after the status column. 

4.2 The age of the material is the number of days 
since the material was added into inventory (see 
calculation used on the Inventory Scan Details 
Report) 



5. Performance Requirements: 

(list any performance 5.1 There should be no noticeable affect on performance. 

requirements associated 

with this change) [Identify 

system response 

requirements that must be 

met for user acceptance] 



6. Dependencies: 

(list any defects or features 6. 1 NONE 
that this enhancement is 
dependent on or that will be 
dependent on this feature) 



7. Benefits: 

(provide benefits in dollars, 7. 1 Give the user the capability of pulling a report 

reduced headcount, time that will give them all the information they need to 

savings, etc. for doing this determine what material should be used first in the 

work) [This is required to yard. This will help them control the cost of doing 

identify any savings that business, 
can be attributed this 
feature for securing 
budget approval] 
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8. Affected Components: (check) (check) 

Yes No 

RTOC Instructions X 

HELP X 

User Guides X 

Testing X 

Infra-structure X 

Management Reports X 

Database X 



9. Interfaces 

(list any legacy or new 9. 1 NONE 

interface systems impacted by 

this change) [Make sure 

other interface systems are 

aware of and agree with any 

requirement change that 

impacts them before 

proceeding] 



10. Work-around: (check) (check) 

Yes No 

(Is there a temporary work X 
around?) 

(describe work around in 10.1 Pull the Inventory Scan 

Details Report 

detail) [Also identify this in 
the OSPCM 'known 
problem' document] 
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11. Risks: 



(list factors that impact, 
positive/negative, not doing 
this change) 



11.1 This change would make the crystal reports available in 
Material Management more user friendly. This will help 
the construction supervisor to track and use the surplus 
and unassigned material in the yards. 



12. Business Rules: 



(list any business rules or 



12.1 NONE 



constraints that should apply. 
If business rules are included 
in the changes section, 
identify these with asterisk in 
bold, ***business rule***) 

13. Documentation Changes: 

(list affected documents 13.1 Functional Decomps 

requiring change) 13.2 Test Scenarios 

[Documentation should 13.3 Material Management Business Solution 

prepare a checklist covering 
each document that must be 
updated for this feature] 
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14. Special Training/Implementation Requirements: 

(list any special 
training/implementation 
required for this feature. 
Identify what will be 
required to train and 
implement this feature to the 
customer, i.e., by 
documentation, e-mail, help, 
cue cards, on sight training, 
etc.) 



15. Acceptance Criteria/Test Scenario: 

(list test scenarios required 15.1 Log on to OSPCM 



to test change prior to user 
acceptance, this can be 
updated after the detailed 
design is completed.) 
REQUIRED [Tester 
should prepare checklist 
based on these test 
scenarios for 
documentation on results 
of tests. These should be 
in matrix form identified 
back to the numbering 
scheme used in these test 
scenarios] 



15.2 Display the Inventory Scan Search Criteria window 

15.3 Run an Inventory Scan 

15.4 After the result of the scan is displayed (Inventory Scan 
Results Window) select print 

15.5 Select print "Inventory Scan Summary" 

15.6 Verify that the age for each material item listed on the report 
is populated 
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16. Attachments: 

(copies of screens, reports, 16.1 NONE 

etc. before and after 

proposed change-only 

identify if the customer 

requires the screen or 

something on the screen to 

look a certain way) 



Signatures of Agreement 

(add additional rows if necessary) 

BAE: (on file) 05/1 1/98 

Lead Analyst: (on file) 05/1 1/98 
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BAE FUNCTIONAL REQUIREMENT DOCUMENT 



Table # 791 5 A 



BAE Start Date: 05/08/1 998 

BAE Comp. Date: 05/08/1998 
BAE Hours: 3 



BAE Name: Mark Seal 

BAE Tele. No.: 205-977-3618 
LA Assigned: 



CMVC Component Name: Workstation 



Associated Defect/Feature No. 



Target Release: 

(give target release this 2.15 
needs to be in) [Only 
identify if this is required 
for an emergency release 
or must be worked in next 
scheduled release] 



Target Release Date: 

(give target release date for 
this enhancement, if required) 



Priority: 

(provide priority from High 
'feature priority' list - 
number preliminary 
assigned by SME) 
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Revision No.: 
Reason for Revision: 



(B, C, etc. - this will require new signatures) 



General: 

(General Information - 
nothing is to be typed here, 
this is for information only 
about the functional spec 
process) 



1 . The purpose of this document is to provide the customer's 
view of the functionality that needs to be changed or added to 
the existing OSPCM product. It is not the detail design 
requirements. It should concentrate on the 'what' that is 
needed and not on the 'how' it is provided. 

2. All features that are > 40 hours/ 1 business area require a structured 
inspection walk through process (currently using FAGAN). This is 
to be scheduled by the responsible SME for this feature with the 
testing team lead, documentation team lead and the IT development 
Managers. The IT develop managers will assign the appropriate 
representatives to attend the meeting. These inspections are not to 
inspect the author, they are to be used to understand the 
functionality required for development of the 'Detail Design 
Document'. 

3. The 'Analysis Phase Specific' checklist must be used, 
documented and baselined for each feature. 

4. Any correspondence associated with this feature should also 
be documented (i.e., impromptu meetings, phone 
conversations, etc.) and associated with the feature number. 
It should include time, date and participants. 

5. Continue numbering scheme in your text input under each to 
provide traceability for matrixes. 



Exh. 2 -Page 126 



1. Abstract: 

(brief description of 1.1 Change the system so that the Bulk reporting screen in 

change/addition) - This workstation will open faster when a CMC is selected and 

should pretty closely match job information is retrieved, 

the abstract in CMVC. 



2. Current Problem: 

(brief description of what 
system currently does, what 
needs to be changed, and 
why) 



2.1 Currently the system takes a very long time to 
open the Bulk reporting screen when a CMC is 
selected and job information is retrieved. This is 
because the system retrieves from the data base all 
jobs, prints and steps when a CMC is selected. 
Then when retrieving substep information and 
associated material information it takes too long to 
populate the substep grid. 



3. Proposed Solution: 

(brief description of what 
the system will or should do 
and any general constraints 
or conditions that limit the 
solution) 



3.1 Change the system so that when selecting a 
CMC on the Bulk screen the system only retrieves 
and displays the job information faster. 

3.2 When the user selects a job, the system should 
retrieve and display the associated prints and steps. 

3.3 When the user selects a step the system should 
retrieve and display in the substep grid the 
substeps and associated material information 
faster. 
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4. Change/Addition(s): 

(detailed description of 4.1 Change the system and/or contracts so that 

change/addition) when selecting a CMC on the Bulk screen the 

system only retrieves and displays the job 

information faster. 

4.2 Change the system and/or contracts so that 
when the user selects a job, the system will 
retrieve and display the associated prints and steps. 

4.3 Change the system and/or contracts so that 
when the user selects a step the system will 
retrieve and display in the substep grid the 
substeps and associated material information 
faster. 

5. Performance Requirements: 

(list any performance 5.1 These should be a great performance 

requirements associated improvement when accessing information on the 

with this change) [Identify Bulk reporting screen due to this feature, 

system response 
requirements that must be 
met for user acceptance] 

6. Dependencies: 

(list any defects or features 6.1 NONE 
that this enhancement is 
dependent on or that will be 
dependent on this feature) 
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7. Benefits: 

(provide benefits in dollars, 
reduced headcount, time 
savings, etc. for doing this 
work) [This is required to 
identify any savings that 
can be attributed this 
feature for securing 
budget approval] 

8. Affected Components: 

RTOC Instructions 
HELP 
User Guides 
Testing 

Infra-structure 
Management Reports 
Database 

9. Interfaces: 

(list any legacy or new 
interface systems impacted 
by this change) [Make sure 
other interface systems are 
aware of and agree with 
any requirement change 
that impacts them before 
proceeding] 



7.1 This change will improve the performance 
the Bulk reporting screens in the workstation 
module 



(check) (check) 
Yes No 

X 
X 
X 
X 
X 
X 
X 



9.1 NONE 
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10. Work-around: 



(check) 



(check) 



Yes 



No 



(is there a temporary work 
around?) 

(describe work around in 
detail) [Also identify this in 
OSPCM 'known problem' 
document] 



10.1 The only work 
around today is to sit and 
wait for the system to 



retrieve all of the data. 



11. Risks: 



(list factors that impact, 
positive/negative, not doing 



11.1 Continued complaints from the users about 
poor system performance. 



this change) 

12. Business Rules: 

(list any business rules or 12.1 Current Business rules should apply. 

constraints that should 

apply. If business rules are 

included in the changes 

section, identify these with 

asterisk in bold, 

***business rule***) 
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13, Documentation Changes: 

(list affected documents 13.1 NONE 

requiring change) 

[Documentation should 

prepare a checklist 

covering each document 

that must be updated for 

this feature] 



14. Special Training/Implementation Requirements: 

(list any special 14.1 NONE 

training/implementation 

required for this feature. 

Identify what will be 

required to train and 

implement this feature to the 

customer, i.e., by 

documentation, e-mail, help, 

cue cards, on sight training, 

etc.) 



15. Acceptance Criteria/Test Scenario: 

(list test scenarios required 
to test change prior to user 
acceptance, this can be 
updated after the detailed 
design is completed.) 
REQUIRED [Tester 
should prepare checklist 
based on these test 



15.1 Verify that when selecting a CMC on the 
Bulk reporting screens the contracts only retrieve 
the Job name. 

15.2 Verify that all open and price firmed job 
names are retrieved. 

15.3 Verify that when selecting a job that the 
system retrieves all prints and steps for the job 
selected. 
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scenarios for 
documentation on results 
of tests. These should be 
in matrix form identified 
back to the numbering 
scheme used in these test 
scenarios] 

16. Attachments: 

(copies of screens, reports, 16.1 NONE 

etc. before and after 

proposed change-only 

identify if the customer 

requires the screen or 

something on the screen to 

look a certain way) 

Signatures of Agreement: 

(add additional rows if necessary) 
BAE: 

Lead Analyst: 



15.4 Verify that when a step is selected that the 
system retrieves and displays all substeps and 
associated material faster. 

15.5 Verifying the increase in performance may 
require that some time studies be done before and 
after the code has been changed. 
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BAE FUNCTIONAL REQUIREMENT DOCUMENT 



Table # 7899A 



BAE Start Date: 05-08-1998 
BAE Comp. Date: 05-08-1998 
BAE Hours: 7 

CMVC Component Name: 

Associated Defect/Feature No.: 



BAE Name: Mark Seal 

BAE Tele. No.: 205-977-3618 
LA Assigned: 

JE-EWO/Configuration/Scheduling 



Target Release: 

(give target release this 2.15 
needs to be in) [Only 
identify if this is required 
for an emergency release 
or must be worked in next 
scheduled release] 



Target Release Date: 

(give target release date for 
this enhancement, if required) 



Priority: 

(provide priority from HIGH 
'feature priority' list - 
number preliminary 
assigned by SME) 
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Revision No.: 
Reason for Revision: 



(B, C, etc. - this will require new signatures) 



General: 

(General Information - 
nothing is to be typed here, 
this is for information only 
about the functional spec 
process) 



1. The purpose of this document is to provide the customer's 
view of the functionality that needs to be changed or added to 
the existing OSPCM product. It is not the detail design 
requirements. It should concentrate on the 'what' that is 
needed and not on the 'how' it is provided. 

2. All features that are > 40 hours/ 1 business area require a structured 
inspection walk through process (currently using FAGAN). This is 
to be scheduled by the responsible SME for this feature with the 
testing team lead, documentation team lead and the IT development 
Managers. The IT develop managers will assign the appropriate 
representatives to attend the meeting. These inspections are not to 
inspect the author, they are to be used to understand the 
functionality required for development of the 'Detail Design 
Document'. 

3. The 'Analysis Phase Specific 5 checklist must be used, 
documented and baselined for each feature. 

4. Any correspondence associated with this feature should also 
be documented (i.e., impromptu meetings, phone 
conversations, etc.) and associated with the feature number. 
It should include time, date and participants. 

5. Continue numbering scheme in your text input under each to 
provide traceability for matrixes. 
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1. Abstract: 

(brief description of 
change/addition) - This 
should pretty closely match 
the abstract in CMVC. 



1.1 Change the configuration process so that each 
time a job is configured before the price is firmed, 
the system will reconfigure the entire job. 

1 .2 Change the configuration process so that when 
a job is re-configured after the price has been 
firmed that the system will attempt to place 
changed and added substeps in the correct existing 
activity. 

1 .3 Change the configuration process so that when 
a substep cannot be placed in an existing activity 
that the system creates an activity and that activity 
is inserted into the existing scheduling network, if 
possible. If not possible, a new scheduling 
network will be created. 



2. Current Problem: 

(brief description of what 
system currently does, what 
needs to be changed, and 
why) 



2.1 Each time a job is configured after the initial 
configuration the system creates "NEW" activities 
for those additional and changed substeps. When 
a job is re-configured, "NEW" activities are 
created and they do not schedule. 



3. Proposed Solution: 

(brief description of what 3.1 Eliminate the "N/E" activity flag in the 

the system will or should do database. This flag identifies a NEW activity 

and any general constraints verses an EXISTING activity. 

or conditions that limit the 3.2 Change the configuration process so that when 
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solution) a job is re-configured and the price is not firmed 

the whole job is reconfigured as if it were the first 
time. This means that the process will re-establish 
all of the activities, activity dependencies, key 
dates and CPM dates. 

3.3 Change the configuration process so that when 
a job is re-configured after the price has been 
firmed any new and/or changed substeps will be 
inserted into an existing activity based on work 
type resource group. 

3.4 When the work type resource group of an 
added or changed substep does not exist on an 
activity within the scheduling network then the 
system will create a new activity. 

3.5 When the system creates an activity it will 
attempt to insert the activity into the existing 
scheduling network based on the current business 
rules associated with using the scheduling 
sequence codes and work types. If it can't, a new 
scheduling network will be created for the activity. 

4. Change/Addition(s): 

(detailed description of 
change/addition) 



4. 1 Change the configuration process so that when 
a job is configured and the price has not been 
firmed then the configuration process will treat the 
job as if it has never been configured. This means 
that the process will establish all of the activities, 
activity dependencies, key dates, date types and 
CPM dates. 

4.2 Change the configuration process so that when 
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a job is configured and the price has already been 
firmed the system will recognize any new or 
changed substep. The system will maintain the 
existing scheduling network(s) and insert the new 
or changed substeps into existing activities based 
on the following business rules. 

4.3 Do not change the network key date. 

4.4 If the new or changed substep has the same 
resource group and work type as an existing 
activity then add the substep to the existing 
activity. 

4.5 If more than one activity has the same work 
type and resource group assigned then insert the 
new or changed substep into the first activity 
found. 

4.6 If there are no existing activities with the same 
work type and resource group then place the new 
or changed substep in a new activity. 

4.7 Place the new activity in the existing 
scheduling network based on the current business 
rules associated with work type resource group 
scheduling sequence codes. If multiple scheduling 
networks exist then try to insert the new activity in 
the oldest network first and then the next oldest 
and so on. 

4.8 If the system can't insert the new activity into 
an existing network then create a new scheduling 
network. 

4.9 Do not add or change key dates, date types 
and priorities on existing scheduling networks. 

4.10 Once all of the new or changed substeps are 
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inserted into an activity if there are any activities 
that do not have a substep then use the existing 
business rules to delete the activity and the 
scheduling network if necessary. See Defect 7987. 
4.11 In those cases where substeps are deleted 
resulting in a need to delete an activity or an entire 
scheduling network then the existing business 
rules will apply. See Defect 7987. 
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5. Performance Requirements: 

(list any performance 
requirements associated 
with this change) [Identify 
system response 
requirements that must be 
met for user acceptance] 



5.1 These changes should result in slightly slower 
performance during the configuration process 
which runs in the back ground and should not 
affect the user. 

5.2 These changes should result in slightly better 
performance for the scheduling module. 



6. Dependencies: 

(list any defects or features 
that this enhancement is 
dependent on or that will be 
dependent on this feature) 



6.1 Defect 7987 This defect corrects the problem of handling 
activities correctly when no substeps are in the activity. 

6.2 Removing the N/E New or Existing flag in the data base will 
affect management reports. 

6.3 Removing the N/E New or Existing flag in the data base will 
affect the GUI in scheduling and workstation modules. 



7. Benefits: 

(provide benefits in dollars, 7.1 All activities will schedule after the price has 

reduced headcount, time been firmed. 

savings, etc. for doing this 7.2 Numerous hours are being spent to handle 

work) [This is required to NEW activities today. 

identify any savings that 7.3 There will be no need to handle New activities 

can be attributed this or scheduling networks in order to schedule work, 
feature for securing 
budget approval] 
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8. Affected Components: (check) (check) 

Yes No 

RTOC Instructions X 

HELP X 

User Guides X 

Testing X 

Infra-structure X 

Management Reports X 

Database X 

9. Interfaces: 

(list any legacy or new 9.1 NONE 



interface systems impacted 
by this change) [Make sure 
other interface systems are 
aware of and agree with 
any requirement change 
that impacts them before 
proceeding] 
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10. Work-around: 

(is there a temporary work 
around?) 

(describe work around in 
detail) [Also identify this in 
OSPCM 'known problem' 
document] 



X 



(check) 
Yes 



10.1 Currently many 
hours are being spent to 
handle the NEW 
activities in order to 
schedule the work in 
these activities. This 
feature will eliminate 
NEW activities and 
therefore schedule all 
work. 



(check) 
No 



11. Risks: 

(list factors that impact, 
positive/negative, not doing 
this change) 



11.1 The users will continue to spend many hours 
handling the NEW activities in order to schedule 
all work. 



12. Business Rules: 

(list any business rules or 
constraints that should 
apply. If business rules are 
included in the changes 
section, identify these with 
asterisk in bold, 
***business rule***) 



12.1 Change the configuration process so that when a job is configured 
and the price has already been firmed the system will recognize 
any new or changed substep. 

12.2 The system will maintain the existing scheduling network(s) and 
insert the new or changed substeps into existing activities based 
on the following business rules. 

• Do not change the network key date. 
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If the new or changed substep has the same resource group and 
work type as an existing activity then add the substep to the 
existing activity. 

If more than one activity has the same work type and resource 
group assigned then insert the new or changed substep into the first 
activity found. 

If there are no existing activities with the same work type and 
resource group then place the new or changed substep in a new 
existing activity. 

Place the new activity in the existing scheduling network based on 
the current business rules associated with work type resource group 
and scheduling sequence codes. If multiple scheduling networks 
exist then try to insert the new activity in the oldest network first 
and then the next oldest and so on. 

If the system can't insert the new activity into an existing network 
then create a new scheduling network. 
Do not add or change key dates, date types and priorities on 
existing scheduling networks. 

Once all of the new or changed substeps are inserted into an 
activity if there are any activities that do not have a substep then 
use the existing business rules to delete the activity and the 
scheduling network if necessary. See Defect 7987. 
In those cases where substeps are deleted resulting in a need to 
delete an activity or an entire scheduling network then the existing 
business rules will apply. See Defect 7987. 
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13. Documentation Changes: 

(list affected documents 13.1 User Guides 

requiring change) 13.2 Help 

[Documentation should 

prepare a checklist 

covering each document 

that must be updated for 

this feature] 



14. Special Training/Implementation Requirements: 



(list any special 
training/implementation 
required for this feature. 
Identify what will be 
required to train and 
implement this feature to the 
customer, i.e., by 
documentation, e-mail, help, 
cue cards, on sight training, 
etc.) 



14.1 User guides 

14.2 Help 

14.3 Job aids 

14.4 Release Notes 

14.5 On-Site training 



15. Acceptance Criteria/Test Scenario: 

(list test scenarios required 
to test change prior to user 
acceptance, this can be 
updated after the detailed 
design is completed.) 
REQUIRED [Tester 
should prepare checklist 
based on these test 



15.1 Encode and configure a new job so that after 
configuration there are at least 3 activities created 
with at least 6 substeps in each activity. Do not 
firm price the job. 

15.2 Add several new substeps to the job and re- 
configure the job. 

15.3 Verify that the whole job re-configured and 
no NEW activities are created. 
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scenarios for 
documentation on results 
of tests. These should be 
in matrix form identified 
back to the numbering 
scheme used in these test 
scenarios] 



15.4 Price firm the job. 

15.5 Add several new substeps and delete at least 
2 substeps and then re-configure the job. 

15.6 Verify that no NEW activity has been 
created. 

15.7 Verify that the deleted substeps are not in any 
activity. 

15.8 Verify that the added substps have been 
inserted into an existing activity. 

15.9 Add a new substep that has a work type that 
does not exist on the job yet. 

15.10 Re-configure the job. 

15.11 Verify that no NEW activity has been 
created. 

15.12 Verify that a new existing activity has been 
created and that it has been placed in the 
scheduling network. 

15.13 Verify that the new activity does not affect 
the existing network key date, date type and 
priority. 

15.14 Delete the substep added on step 15.9 and 
configure the job. 

15.15 Verify that the last activity created was 
deleted during the last configuration. 
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16. Attachments: 

(copies of screens, reports, 16.1 NONE 

etc. before and after 

proposed change-only 

identify if the customer 

requires the screen or 

something on the screen to 

look a certain way) 
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Signatures of Agreement: 

(add additional rows if necessary) 

BAE: 

Lead Analyst: 



(on file) 5/14/98 
(on file) 5/14/98 
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BAE FUNCTIONAL REQUIREMENT DOCUMENT 



Table # 7947B 



BAE Start Date: 
BAE Comp. Date: 
BAE Hours: 



04/16/1998 
04/23/1998 
3 



BAE Name: 
BAE Tele. No. 
LA Assigned: 



Gail W. Deaton 
205-977-3615 



CMVC Component Name: 



jeewo 



Associated Defect/Feature No.: 



Target Release: 
(give target release this 
needs to be in) [Only 
identify if this is required 
for an emergency release 
or must be worked in next 
scheduled release] 



2.14 



Target Release Date: 

(give target release date for 6/1998 
this enhancement, if required) 



Priority: 

(provide priority from 
'feature priority' list - 
number preliminary 
assigned by SME) 



Hi 
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Revision No.: 
Reason for Revision: 



(B, C, etc. - this will require new signatures) 
Walkthru results and change target release 



General: 

(General Information - 
nothing is to be typed here, 
this is for information only 
about the functional spec 
process) 



1 . The purpose of this document is to provide the customer's 
view of the functionality that needs to be changed or added to 
the existing OSPCM product. It is not the detail design 
requirements. It should concentrate on the 'what' that is 
needed and not on the 'how' it is provided. 

2. All features that are > 40 hours/1 business area require a structured 
inspection walk through process (currently using FAGAN). This is 
to be scheduled by the responsible SME for this feature with the 
testing team lead, documentation team lead and the IT development 
Managers. The IT develop managers will assign the appropriate 
representatives to attend the meeting. These inspections are not to 
inspect the author, they are to be used to understand the 
functionality required for development of the 'Detail Design 
Document'. 

3. The 'Analysis Phase Specific' checklist must be used, 
documented and baselined for each feature. 

4. Any correspondence associated with this feature should also 
be documented (i.e., impromptu meetings, phone 
conversations, etc.) and associated with the feature number. 
It should include time, date and participants. 

5. Continue numbering scheme in your text input under each to 
provide traceability for matrixes. 
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1. Abstract: 

(brief description of 1.1 Make the default for the Est. Comp. Date in 

change/addition) - This job_ewo 120 days from the current date, 

should pretty closely match 
the abstract in CMVC. 



2. Current Problem: 

(brief description of what 
system currently does, what 
needs to be changed, and 
why) 



2.1 Currently the default for the Est. Comp. Date 
is 30 days from today's date. Designers are not 
properly changing the date to a realistic date. 
When the job is FIRMed in Pricing and sent to 
BCAS the approval date is after the Est. Comp. 
Date. This is causing BCAS errors to be 
generated. 



3. Proposed Solution: 

(brief description of what 
the system will or should do 
and any general constraints 
or conditions that limit the 
solution) 



3.1 Make the default for the Est. Comp. Date in 
job_ewo 120 days from the current date. This 
should eliminate most of the BCAS errors. 



4. Change/Addition(s): 

(detailed description of 
change/addition) 



4.1 The Est. Comp. Date currently defaults to 30 
days from the current date. With this feature, this 
date will default to the current date + 120 days. 
This will be the default for the creation of EWO 
and PWO jobs. In addition, when the user selects 
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to clone a job, the Est. Comp. Date will default to 
the current date +120 days. The user can change 
the Est. Comp. Date, but it must be the current 
date or a future date. 



5. Performance Requirements: 

(list any performance 
requirements associated 
with this change) [Identify 
system response 
requirements that must be 
met for user acceptance] 

6. Dependencies: 

(list any defects or features 
that this enhancement is 
dependent on or that will be 
dependent on this feature) 



7. Benefits: 

(provide benefits in dollars, 7.1 Eliminates BCAS errors generated to the 

reduced headcount, time users. Savings in the time it takes to investigate 

savings, etc. for doing this and correct these errors, 

work) [This is required to 
identify any savings that 
can be attributed this 
feature for securing 
budget approval] 



Exh.2-Pagel50 



8. Affected Components: (check) (check) 

Yes No 

RTOC Instructions X 

HELP X 

User Guides X 

Testing X 

Infra-structure X 

Management Reports X 

Database X 



9. Interfaces: 

(list any legacy or new 
interface systems impacted 
by this change) [Make sure 
other interface systems are 
aware of and agree with 
any requirement change 
that impacts them before 
proceeding] 

10. Work-around: 

(is there a temporary work 
around?) 

(describe work around in 
detail) [Also identify this 
in OSPCM 'known 
problem' document] 
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(check) (check) 
Yes No 

X 



11. Risks: 

(list factors that impact, 
positive/negative, not doing 
this change) 

12. Business Rules: 

(list any business rules or 
constraints that should 
apply. If business rules are 
included in the changes 
section, identify these with 
asterisk in bold, 
***business rule***) 

13. Documentation Changes: 
(list affected documents 
requiring change) 
[Documentation should 
prepare a checklist 
covering each document 
that must be updated for 
this feature] 



11.1 User acceptance and BCAS response. 



13.1 On Line Help show the default for the Est. 
Comp. Date is 120 days from the current date. 
Indicate that this date can be changed by the user. 
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14. Special Training/Implementation Requirements: 

(list any special 
training/implementation 
required for this feature. 
Identify what will be 
required to train and 
implement this feature to the 
customer, i.e., by 
documentation, e-mail, help, 
cue cards, on sight training, 
etc.) 



15. Acceptance Criteria/Test Scenario: 

(list test scenarios required 

to test change prior to user 

acceptance, this can be 

updated after the detailed 

design is completed.) 

REQUIRED [Tester 

should prepare checklist 

based on these test 

scenarios for 

documentation on results 

of tests. These should be 

in matrix form identified 

back to the numbering 

scheme used in these test 

scenarios] 



15.1 

Enter a new EWP type job in job_entry. Check to 
make sure the Est. Comp. Date default is 120 days 
from today. 

Enter a new PWO type job in job_entry. Check to 
make sure the Est. Comp. Date default is 120 days 
from today. 

Test to see if the default date of 120 days from 
today can be changed to the current date or a 
future date. 

Enter a past date in the Est. Comp. Date. Verify 

that an error message is generated. 

Select the refresh button, the Est. Comp. Date 

should be reset to the current date +120 days. 

15.2 

Clone a job. Verify that the default Est. Comp. 
Date is 120 days from the current date. 
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16. Attachments: 

(copies of screens, reports, 
etc. before and after proposed 
change-only identify if the 
customer requires the screen 
or something on the screen to 
look a certain way) 

Signatures of Agreement: 

(add additional rows if necessary) 
BAE: 

Lead Analyst: 



BAE FUNCTIONAL REQUIREMENT DOCUMENT 



Table # 8101A 



BAE Start Date: 
BAE Comp. Date: 
BAE Hours: 



05/18/1998 
05/18/1998 
1 



BAE Name: 
BAE Tele. No. 
LA Assigned: 



Wesley White 
977-7436 



CMVC Component Name: 



Mgmtjeports 



Associated Defect/Feature No. 



8101 



Target Release: 
(give target release this 
needs to be in) [Only 
identify if this is required 
for an emergency release 
or must be worked in next 
scheduled release] 



2.14 



Target Release Date: 

(give target release date for 
this enhancement, if required) 



Priority: 

(provide priority from 
'feature priority 5 list — 
number preliminary 
assigned by SME) 
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Revision No.: 
Reason for Revision: 



(B, C, etc. - this will require new signatures) 



General: 

(General Information - 
nothing is to be typed here, 
this is for information only 
about the functional spec 
process) 



1 . The purpose of this document is to provide the customer's 
view of the functionality that needs to be changed or added to 
the existing OSPCM product. It is not the detail design 
requirements. It should concentrate on the 'what' that is 
needed and not on the 'how' it is provided. 

2. All features that are > 40 hours/ 1 business area require a structured 
inspection walk through process (currently using FAGAN). This is 
to be scheduled by the responsible SME for this feature with the 
testing team lead, documentation team lead and the IT development 
Managers. The IT develop managers will assign the appropriate 
representatives to attend the meeting. These inspections are not to 
inspect the author, they are to be used to understand the 
functionality required for development of the 'Detail Design 
Document'. 

3. The 'Analysis Phase Specific' checklist must be used, 
documented and baselined for each feature. 

4. Any correspondence associated with this feature should also 
be documented (i.e., impromptu meetings, phone 
conversations, etc.) and associated with the feature number. 
It should include time, date and participants. 

5. Continue numbering scheme in your text input under each to 
provide traceability for matrixes. 
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1. Abstract: 

(brief description of 
change/addition) - This 
should pretty closely match 
the abstract in CMVC. 



1 . 1 Add a new variable to indicate if the requested 
report should be sent directly to the printer or 
returned to the screen for online viewing. 



2. Current Problem: 

(brief description of what 
system currently does, what 
needs to be changed, and 
why) 



2.1 Currently the user only has the option of 
printing the report AFTER it has been returned to 
the screen. 



3. Proposed Solution: 

(brief description of what 
the system will or should do 
and any general constraints 
or conditions that limit the 
solution) 



3.1 Allow the user the choice of sending the 
selected report directly to the printer or viewing it 
online to improve performance. This requires a 
variable to be passed with the report request. 
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4. Change/Addition(s): 

(detailed description of 
change/addition) 



4.1 When user selects a report vbfile.ftm is 



created. It is a comma delimited file of the 



variables the user has selected. Add an additional 
variable to vbfile.ftm. Add a checkbox to the vb 
screen with a title of "Send To Printer". If the user 
checks the checkbox populate a "y" in the variable 
in vbfile.ftm. If the user does not check the 
checkbox populate a "n" in vbfile.ftm. The 
checkbox should work the same as the other 
prompts on the vb screen. The checkbox should 
only be activated for reports where the prompt is 
turned on, by reading the prompts from admin 
module. Include help file for context # 125500043 
to Fl key for field "return after preview". 



5. Performance Requirements: 

(list any performance 
requirements associated 
with this change) [Identify 
system response 
requirements that must be 
met for user acceptance] 



application should be improved because the user 
won't have to wait for the report to be returned to 
the screen if they only want to print a copy of the 



report. 



5.1 Performance of the Management Reports 



6. Dependencies: 

(list any defects or features 6.1 NONE 



that this enhancement is 



dependent on or that will be 
dependent on this feature) 
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7. Benefits: 

(provide benefits in dollars, 
reduced headcount, time 
savings, etc. for doing this 
work) [This is required to 
identify any savings that 
can be attributed this 
feature for securing 
budget approval] 



8. Affected Components: (check) (check) 

Yes No 
RTOC Instructions X 
HELP X 
User Guides X 
Testing X 

Infra-structure X 
Management Reports X 

Database X 

9. Interfaces: 

(list any legacy or new 9.1 NONE 



interface systems impacted 
by this change) [Make sure 
other interface systems are 
aware of and agree with 
any requirement change 
that impacts them before 
proceeding] 



7.1 The user won't have to wait for the report to 
be returned to the screen if they only want to print 
a copy of the report. 
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10. Work-around: 



(check) 



(check) 



Yes 



No 



(is there a temporary work 



X 



around?) 

(describe work around in 
detail) [Also identify this in 
OSPCM 'known problem' 
document] 

11. Risks: 

(list factors that impact, 11.1 If feature is not worked poor performance 

positive/negative, not doing of mgmt reports will continue. User will have to 

this change) wait until report is formatted to screen before 



choosing to print the report. 



12. Business Rules: 



(list any business rules or 



12.1 When the Send to Printer check box is activated a variable of Y 



apply. If business rules are 
included in the changes 
section, identify these with 
asterisk in bold, 
***business rule***) 



constraints that should 



should be written to the vbfile file. If the send to printer 
check box is not checked a N should be written to the file. 
The Send to printer check box should only be activated if 
specified for the particular report being run. 
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13. Documentation Changes: 

(list affected documents 13.1 Management Reports, Online Help and User Guide 

requiring change) 

[Documentation should 

prepare a checklist 

covering each document 

that must be updated for 

this feature] 

14 Special Training/Implementation Requirements: 

(list any special 14.1 Release Notes 

training/implementation 

required for this feature. 

Identify what will be 

required to train and 

implement this feature to the 

customer, i.e., by 

documentation, e-mail, help, 

cue cards, on sight training, 

etc.) 
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15. Acceptance Criteria/Test Scenario: 

(list test scenarios required 15.1 1 .)Verify that you can turn the check-box off and on for various 

to test change prior to user reports, 2.) request a report and send it directly to the printer and 3.) 

acceptance this can be request a report and view it on-line as is currently designed 4.) verify 

updated after the detailed v/or ^ s ^ or return a f ter P rey i ew an d send to printer. 

design is completed.) 

REQUIRED [Tester should 

prepare checklist based on 

these test scenarios for 

documentation on results of 

tests. These should be in 

matrix form identified back 

to the numbering scheme 

used in these test scenarios] 



16. Attachments: 

(copies of screens, reports, 
etc. before and after 
proposed change-only 
identify if the customer 
requires the screen or 
something on the screen to 
look a certain way) 



Signatures of Agreement: 

(add additional rows if necessary) 

BAE: (on file) 5/28/98 

Lead Analyst: (on file) 5/28/98 
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BAE FUNCTIONAL REQUIREMENT DOCUMENT 



Table # 8102B 



BAE Start Date: 
BAE Comp. Date: 
BAE Hours: 



05/18/1998 
05/30/1998 
3 



BAE Name: 
BAE Tele. No,: 
LA Assigned: 



Wesley White 
977-7436 



CMVC Component Name: 



Pricing, job entry, management reports 



Associated Defect/Feature No.: 



8102 



Target Release: 
(give target release this 
needs to be in) [Only 
identify if this is required 
for an emergency release 
or must be worked in next 
scheduled release] 



Target Release Date: 

(give target release date for 
this enhancement, if required) 



Priority: 

(provide priority from 
'feature priority' list - 
number preliminary 
assigned by SME) 
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Revision No.: B (B, C, etc. - this will require new signatures) 

Reason for Revision: Add additional functionality 



General: 

(General Information - 
nothing is to be typed here, 
this is for information only 
about the functional spec 
process) 



1 . The purpose of this document is to provide the customer's 
view of the functionality that needs to be changed or added to 
the existing OSPCM product. It is not the detail design 
requirements. It should concentrate on the 'what' that is 
needed and not on the 'how' it is provided. 

2. All features that are > 40 hours/ 1 business area require a structured 
inspection walk through process (currently using FAGAN). This is 
to be scheduled by the responsible SME for this feature with the 
testing team lead, documentation team lead and the IT development 
Managers. The IT develop managers will assign the appropriate 
representatives to attend the meeting. These inspections are not to 
inspect the author, they are to be used to understand the 
functionality required for development of the 'Detail Design 
Document'. 

3. The 'Analysis Phase Specific' checklist must be used, 
documented and baselined for each feature. 

4. Any correspondence associated with this feature should also 
be documented (i.e., impromptu meetings, phone 
conversations, etc.) and associated with the feature number. 
It should include time, date and participants. 

5. Continue numbering scheme in your text input under each to 
provide traceability for matrixes. 
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1. Abstract: 



(brief description of 
change/addition) - This 
should pretty closely match 



1 . Capture initial approval date and original 
sti_time_qty to create "Encoding Audit Report". 
BUFIT file to gain shar m asur ments group. 



the abstract in CMVC. 



Definitions: 

a) Initial approval date - the date the first time the job is firmed 
in ospcm 

b) Original sti_time_qty - amount of sti_time_qty on substep at 
initial approval date 

c) Actual sti_time_qty - the amount in the sti_time_qty field on 
a substep as it exists now. 

d) Period of batch process - time period the batch process is 
being run for, the process needs to run at least once a month 
to calculate a months worth of data. For example, the process 
might run on 1 st to calculate amounts on all completed and 
cancelled substeps from the 1 st to the 31 st of the previous 
month. It should retain a rolling 12 months data. 



substep_sti quantity have been made. The users 
cannot determine which steps are added after the 
first approval and cannot tell how much change 
there may be in sti_time_qty from time of 
encoding to completion. The users need the data 



2. Current Problem: 



(brief description of what 
system currently does, what 
needs to be changed, and 
why) 



2.1 Currently the system overwrites the approval 
date each time the job is firmed, and the system 
overwrites the sti_time_qty for a substep each time 
a job is reconfigured and changes that affect the 
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to create the "Encoding Audit Report". The gain 
share group needs a file to be bufited to them 
for loading into their database. The dollars 
spent on EXHB L001A and E001A CWIs must 
be tracked for use in gain share measurement. 



3. Proposed Solution: 

(brief description of what 
the system will or should do 
and any general constraints 
or conditions that limit the 
solution) 



3.1 Add database fields to capture 

A. ) "initial approval date" of job 

B. ) "original sti_time_qty" for all substeps on a job at time of 
approval. 

3.2 Create batch process to calculate percent 
difference between sum of "original sti_time_qty" 
and sum of "actual sti_time_qty" for all substeps 
completed or canceled for "period of batch 
process". The sti fields should be summed first on 
all substeps within an rc_cd and wirecenter then 
the difference calculated. 



3.3 BUFIT a copy of file that will be updated in new database 
to the gain share group. 
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4. Change/Addition(s): 

(detailed description of 
change/addition) 



4.1 JOB ENTRY 

A. ) create new field to capture "original 
sti_time_qty" 

B. ) When a substep is entered in job_entry the 
"original sti_time_qty" should be populated with 0 

C. ) When an existing substep is updated in job 
entry the process should not repopulate "original 
stij:ime_qty" 

D. ) The "actual sti_time_qty" field should work as 
it currently does 

E. ) Add a date of deletion field to the database. 
Populate the field with the current date when a 
substep is canceled or deleted. 

4.2 PRICING 

A. ) Capture "initial approval date" of job - this 
date should be captured in pricing at the time the 
job is firmed. The existing approval date field 
should not change and should continue to function 
as it currently does. 

B. ) On clicking the firm button the process should 
check to see if "initial approval date" is populated. 

1. If "initial approval date" is not populated 
populate the current approval_dt field and 

a. ) populate "initial approval date" field with the 
approval date 

b. ) copy sti_time_qty on all existing substeps to 
"original sti_time_qty" 

2. If "initial approval date" is populated 

a.) populate current approval date field and do not 
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repopulate "initial approval date" 

b.) do not repopulate "original sti Jime_qty" 

4.3 MANAGEMENT REPORTS 

A. ) Create batch process to capture: 

1 . "original sti_time_qty" 

2. "Actual sti_time_qty" 

3. PERCENT Difference between "original 
sti_time_qty" and "actual_time_qty" completed or 
canceled substeps during "period of batch run" 

4. CMC of job of substep 

5. Rc_cd of resid of substep 

6. Wirecenter of substep 

7. Total # of complete substeps for rc_cd and 
wirecenter for period of batch run 

8. Month/year of completion for substeps for 
which batch process is being run 

9. Total dollars spent on L001 A Exhibit B 

10. Total dollars spent on E001A Exhibit B 

SEE ATTACHED FOR 9 and 10 

B. Data should be stored by CMC, by Wirecenter, 
by rc_cd 

C. Data should be calculated only for EWO jobs 
and PWO jobs where the fourth digit of the 
jobjnbr is an 'E\ Exclude exhibit B work xc pt 
for calculating total dollars spent on completed 
EXHB sust ps with L001 A and E001A CWIs 
during the period of the batch run. 

D. Data should only contain jobs that are 
approved. 

E. Data should contain only substeps complete, 
canceled, or deleted during period of batch run. 
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F. Batch run should ran at least once a month to 
calculate the full previous months data. 

G. A flat file should be bufited to the gain share 
group each time the process is run and contain the 
information that will be populated in the batch 
process table. Using a numbering scheme for the 
file so that the bufit group can determine which 
server and when the file was sent, such as 
AL271498 

H. The should retain a rolling 12 month data. 



5. Performance Requirements: 

(list any performance 
requirements associated 
with this change) [Identify 
system response 
requirements that must be 
met for user acceptance] 



5.1 Performance should be improved because 
batch process will calculate data faster than focus. 



6. Dependencies: 

(list any defects or features 6. 1 NONE 



that this enhancement is 



dependent on or that will be 
dependent on this feature) 
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7. Benefits: 

(provide benefits in dollars, 
reduced headcount, time 
savings, etc. for doing this 
work) [This is required to 
identify any savings that 
can be attributed this 
feature for securing 
budget approval] 



7.1 Currently some of this data cannot be 
calculated and requires manual effort to calculate 
this process will reduce effort needed to calculate 
this information. 
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8. Affected Components: 



(check) 
Yes 



No 



(check) 



RTOC Instructions 
HELP 
User Guides 
Testing 

Infra-structure 
Management Reports 
Database 

9. Interfaces: 

(list any legacy or new 
interface systems impacted 
by this change) [Make sure 
other interface systems are 
aware of and agree with 
any requirement change 
that impacts them before 
proceeding] 

10. Work-around: 

(is there a temporary work 
around?) 

(describe work around in 
detail) [Also identify this in 
OSPCM 'known problem' 
document] 



X 
X 

X 
X 
X 
X 
X 



9.1 NONE 



(check) 
Yes 



(check) 
No 

X 
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11. Risks: 

(list factors that impact, 
positive/negative, not doing 
this change) 

12. Business Rules: 

(list any business rules or 
constraints that should 
apply. If business rules are 
included in the changes 
section, identify these with 
asterisk in bold, 
***business rule***) 



11.1 Improved performance and ability to 
calculate information not currently in system. 



12.1 JOB ENTRY 

A. ) create new field to capture "original 
sti_time_qty" 

B. ) When a substep is entered in job entry the 
"original sti_time_qty" should be populated 
withO 

C. ) When an existing substep is updated in job 
entry the process should not repopulate "original 
sti_time_qty" 

D. ) The "actual sti_time_qty" field should work 
as it currently does 

E. ) Add a date of deletion field to the database. 
Populate the field with the current date when a 
substep is canceled or deleted. 

12.2 PRICING 

A. ) Capture "initial approval date" of job - this 
date should be captured in pricing at the time the 
job is firmed. The existing approval date field 
should not change and should continue to function 
as it currently does. 

B. ) On clicking the firm button the process 
should check to see if "initial approval date" is 
populated. 
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1. If "initial approval date" is not populated 

a. ) populate the current approval_dt field 
and populate "initial approval date" field 
with the approval date 

b. ) copy sti_time_qty on all existing 
substeps to "original sti_time_qty" 

2. If "initial approval date" is populated 

a. ) populate current approval date field 
and do not repopulate "initial approval date" 

b. ) do not repopulate "original 
sti_tirne_qty" 

12.3 MANAGEMENT REPORTS 
A.) Create batch process to capture: 

1 . "original sti_time_qty" 

2. "Actual sti_time_qty" 

3. PERCENT Difference between "original 
sti_time_qty" and "actual_time_qty" completed or 
canceled substeps during "period of batch run" 

4. CMC of job of substep 

5. Rc_cd of resid of substep 

6. Wirecenter of substep 

7. Total # of complete subteps for rc_cd and 
wirecenter for period of batch run 

8. Month/year of completion for substeps 
for which batch process is being run 

9. Total dollars spent on L001 A Exhibit 

B 

10. Total dollars spent on E001A Exhibit 

B 

SEE ATTACHED FOR 9 and 10 
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B. ) Data should be stored by CMC, by Wirecenter, by rc_cd 

C. ) Data should be calculated only for EWO jobs and PWO 
jobs where the fourth digit of the jobjibr is an 'E\ Exclude 
exhibit B work except for calculating total dollars spent on 
completed EXHB substeps with L001 A and E001A CWIs 
during the period of the batch run. 

D. ) Data should only contain jobs that are approved. 

E. ) Data should contain only substeps complete, canceled, or deleted 
during period of batch run. 

F. ) Batch run should run at least once a month to calculate the full 
previous months data 

G. ) The should retain a rolling 12 months data. 
13. Documentation Changes: 

(list affected documents 13.1 user guides for mgmt reports, rtoc instructions for batch process 

requiring change) 

[Documentation should 

prepare a checklist 

covering each document 

that must be updated for 

this feature] 
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14. Special Training/Implementation Requirements: 

(list any special 14.1 release notes, rtoc instructions 



training/implementation 
required for this feature. 
Identify what will be 
required to train and 
implement this feature to the 
customer, i.e., by 
documentation, e-mail, help, 
cue cards, on sight training, 
etc.) 

15 Acceptance Criteria/Test Scenario: 

(list any special 15.1 JOB ENTRY 

training/implementation A.) create new field to capture "original 

required for this feature. sti_time_qty" 

Identify what will be B.) When a substep is entered in job_entry the 

required to train and "original sti_time_qty" should be populated with 0 

implement this feature to the C.) When an existing substep is updated in job entry the process 



customer, i.e., by 
documentation, e-mail, help, 
cue cards, on sight training, 
etc.) 



should not repopulate "original sti_time_qty" verify "original 

sti_time_qty" field is not affected by update 

D.) The "actual sti_time_qty" field should work as it currently 



does 



E.) Date Deleted field should be populated if a substep is 



canceled or deleted. 



15.2 PRICING 



A.) Create "initial approval date" field in database field should 



exist in database 



B.) Capture "initial approval date" of job - this date should be 
captured in pricing at the time the job is firmed. The 
existing approval date field should not change and should 
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continue to function as it currently does. Verify existing 
approval date field works as it currently does. 
C.) On clicking the firm button the process should check to see 
if "initial approval date" is populated. 

1 . If "initial approval date" is not populated 

a. ) populate the current approval_dt field and populate 

"initial approval date" field with the approval date. 

b. ) Copy sti_time_qty on all existing substeps to 

"original sti_timejqty" 

Verify if initial approval date is not populated that it 
gets populated with the approval date when the job 
is firmed. Verify that the original sti_time_qty field 
is populated with sti-time-qty when job is firmed. 

2. if "initial approval date" is populated 

a. ) populate current approval date field and do not 

repopulate "initial approval date" 

b. ) do not repopulate "original sti_time_qty" 

Verify that if initial approval date is populated that 
if job is refirmed that initial approval date is not 
overwritten. Verify that the original sti-time-qty 
fields are not overwritten 

15.3 MANAGEMENT REPORTS 

A.) Create batch process to capture: 

1 . "original sti_time_qty" 

2. "Actual sti_time_qty" 

3. PERCENT Difference between "original stijime_qty" 
and "actual_time_qty" completed or canceled substeps 
during "period of batch run" 

4. CMC of job of substep 

5 . Rc_cd of resid of substep 

6. Wirecenter of substep 



Exh. 2 -Page 176 



7. Total # of complete substeps for rc_cd for period of batch 
run 

8. Month of completion for substeps for which batch 
process is being run 

B. ) Data should be stored by CMC, by Wirecenter, by rc_cd 

C. ) Data should be calculated only for EWO and EWO jobs and 

PWO jobs where the fourth digit of the jobjnbr is an 'E\ 
Exclude exhibit B work except for calculating total dollars 
spent on completed EXHB substeps with L001 A and 
E001 A CWIs during the period of the batch run. 

D. ) Data should only contain jobs that have an approval_dt 

E. ) Data should contain only substeps complete or canceled 

during period of batch run. Batch run should run at least 
once a month to calculate the full previous months data. 

F. ) A flat file should be bufited to the gain share group each 

time the process is run and contain the information that 
will be populated in the batch process table. Using a 
numbering scheme for the file so that the bufit group can 
determine which server and when the file was sent, such 
as AL271498. 

should store data as described above. 
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16. Attachments: 

(copies of screens, reports, 1 6. 1 NONE 

etc. before and after 

proposed change-only 

identify if the customer 

requires the screen or 

something on the screen to 

look a certain way) 



Signatures of Agreement: 

(add additional rows if necessary) 

BAE: (on file) 7/17/98 

Lead Analyst: (on file) 7/17/98 
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BAE FUNCTIONAL REQUIREMENT DOCUMENT 



Table # 81 92 A 



BAE Start Date: 06/15/98 
BAE Comp. Date: 06/19/98 
BAE Hours: 4 



BAE Name: 
BAE Tele. No.: 
LA Assigned: 



Steve Kaminski 
977-2646 



CMVC Component Name: 



All OSPCM Applications 



Associated Defect/Feature No. 



NA 



Target Release: 
(give target release this 
needs to be in) [Only 
identify if this is required 
for an emergency release 
or must be worked in next 
scheduled release] 



2.15 



Target Release Date: 

(give target release date for 
this enhancement, if required) 



Priority: 

(provide priority from 
'feature priority' list - 
number preliminary 
assigned by SME) 
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Revision No.: 
Reason for Revision 



(B, C, etc. - this will require new signatures) 



General: 

(General Information - 
nothing is to be typed here, 
this is for information only 
about the functional spec 
process) 



1 . The purpose of this document is to provide the customer's 
view of the functionality that needs to be changed or added to 
the existing OSPCM product. It is not the detail design 
requirements. It should concentrate on the 'what' that is 
needed and not on the 'how' it is provided. 

2. All features that are > 40 hours/ 1 business area require a structured 
inspection walk through process (currently using FAG AN). This is 
to be scheduled by the responsible SME for this feature with the 
testing team lead, documentation team lead and the IT development 
Managers. The IT develop managers will assign the appropriate 
representatives to attend the meeting. These inspections are not to 
inspect the author, they are to be used to understand the 
functionality required for development of the 'Detail Design 
Document'. 

3. The 'Analysis Phase Specific' checklist must be used, 
documented and baselined for each feature. 

4. Any correspondence associated with this feature should also 
be documented (i.e., impromptu meetings, phone 
conversations, etc.) and associated with the feature number. 
It should include time, date and participants. 

5. Continue numbering scheme in your text input under each to 
provide traceability for matrixes. 
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1. Abstract: 

(brief description of 
change/addition) - This 
should pretty closely match 
the abstract in CMVC. 



1 . 1 This is a simple feature that adds a macro to 
each current HLP file within OSPCM allowing the 
user to access the OSPCM web site. The user 
would select various jump-links within a HLP file 
to display a job aid, OSPCM Product Bulletin, or 
specific document web page for an OSPCM User 
Guide from the OSPCM web site. 



2. Current Problem: 

(brief description of what 
system currently does, what 
needs to be changed, and 
why) 



2.1 The OSPCM web site is used to store most 
user documentation for OSPCM. This 
documentation consists of user guides, job aids, 
known workarounds and product bulletins. A user 
may or may not know what information is 
contained on this web site. As a result users are 
not using the web as much as they should or if 
they are they must access the OSPCM web site 
and search the associated pages for the 
documentation. 



3. Proposed Solution: 

(brief description of what 3.1 The proposed solution provides quick access 

the system will or should do to the OSPCM web site from the online help 

and any general constraints (which is already part of an OSPCM application), 

or conditions that limit the Specific links can be provided that the user can 

solution) select and go straight to the web site information. 
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For example, if a user is on the Splicing Tab for 
the Job Entry application and accesses the online 
help for information, there will be a link to the 
web site stating "For further information about 
encoding underground splicing work click here to 
display the Job Aid information." 



4. Change/Addition(s): 

(detailed description of 
change/addition) 



4. 1 Create a new macro that contains the command script and 
appropriate parameters. (The macro command is the same, 
the only parameter change is the actual web site address such 
as ("ttp:/ospcm.bst.bls.com"or 
"http:/ospcm.bst.blx.com/pages/ospdocs.htm#jobaid") 

4.2 Add one new DLL INETWH16 (provided with the RoboHelp 
product) to access the web site from the online help. 

4.3 Add macro routine to the Configuration section of the project 
file (HP J) within each HLP file. 

4.4 Add a standard OSPCM web icon (to jump to the web site) to 
each application's contents help topic. 

4.5 Add a "shortcut" icon for appropriate jumps to job aids, user 
guides, and product bulletins within each help file of an 
application. 

4.6 Add key word of "web" to any jumps to the web for search 
capability. 

4.7 Update How to Use OSPCM Help topic to include 
instructions on accessing the web site from the help file. 

4.8 Add new DLL INETWH16 to CMVC Help component. This 
DLL must be included in the Help directory for the OSPCM 
build package. 
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5. Performance Requirements: 

(list any performance 5.1 There will be no impact on performance to any OSPCM 

requirements associated applications as a result of this feature. 

with this change) [Identify 

system response 

requirements that must be 

met for user acceptance] 



6. Dependencies: 

(list any defects or features 6.1 NONE 
that this enhancement is 
dependent on or that will be 
dependent on this feature) 



7, Benefits: 

(provide benefits in dollars, 7. 1 Provides the user with direct access to current 

reduced headcount, time updated OSPCM documentation, 

savings, etc. for doing this 7.2 Speeds up user tasks when information is 

work) [This is required to readily available such as going to the Job Aid 

identify any savings that when encoding underground splicing work, 
can be attributed this 
feature for securing 
budget approval] 
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8. Affected Components: 



(check) 
Yes 



(check) 

No 



RTOC Instructions 
HELP 
User Guides 
Testing 

Infra-structure 
Management Reports 
Database 

9. Interfaces: 
(list any legacy or new 
interface systems impacted 
by this change) [Make sure 
other interface systems are 
aware of and agree with 
any requirement change 
that impacts them before 
proceeding] 



X 



X 
X 



9.1 Need to coordinate with the OSPCM Web Master for any 
changes or additions to the current page/web structure. For 
example, if there is a jump to a job aid on the 
Documentation page and a new page was developed for 
only job aids, there could be a corrupted link from the 
online help. 
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10. Work-around: 



(check) 
Yes 



(check) 
No 



X 

10.1 User would have to 
access the OSPCM web 
site from outside the 
OSPCM application and 
search for the appropriate 
information. 

11. Risks: 

(list factors that impact, 11.1 A user may not know what information is 

positive/negative, not doing contained on the OSPCM web site, 
this change) 



(is there a temporary work 
around?) 

(describe work around in 
detail) [Also identify this in 
OSPCM 'known problem' 
document] 



12. Business Rules: 

(list any business rules or 
constraints that should 
apply. If business rules are 
included in the changes 
section, identify these with 
asterisk in bold, 
***business rule***) 



Currently all BellSouth terminals are required to have Netscape 
as part of their standard load. 

12. 1 Add to the How to Use OSPCM Help topic, information 
about having Netscape installed in order to access the 
OSPCM web site. 

12.2 Create a pop-up for the following words "OSPCM web 
site." This pop-up will display the following text when a 
user places their cursor on these words (which will be in 
green and underlined) "You must have Netscape installed 
in order to access the OSPCM web site." 

12.3 In the event that a terminal does not have Netscape (or any 
other web browser) and the user selects an Internet 
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jump/link then an error message will pop up stating that the 
"Routine was not found." They click OK and can continue 
onto their next task. This is a standard Microsoft error 
message for this type of occurrence. 



13. Documentation Changes: 
(list affected documents 13.1 Online Help 
requiring change) 
[Documentation should 
prepare a checklist 
covering each document 
that must be updated for 
this feature] 



13.2 Overview chapters of user guides about online help 

13.3 System Overview Guide section about accessing the web 
site. 



14. Special Training/Implementation Requirements: 

(list any special 14.1 Add statement to the main OSPCM home page introducing 

training/implementation this new feature. 

required for this feature. 14.2 Add instructions to the How to Use OSPCM Help topic to 

Identify what will be include accessing the OSPCM web site. 

required to train and 

implement this feature to the 

customer, i.e., by 

documentation, e-mail, help, 

cue cards, on sight training, 

etc.) 



15. Acceptance Criteria/Test Scenario: 

(list test scenarios required For each application: 

to test change prior to user 15.1 Access the OSPCM Guide. 

acceptance, this can be 15.1.1 Select an application. 
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updated after the detailed 
design is completed.) 
REQUIRED [Tester 
should prepare checklist 
based on these test 
scenarios for 
documentation on results 
of tests. These should be 
in matrix form identified 
back to the numbering 
scheme used in these test 
scenarios] 



15.2 Select the Help icon from the toolbar. 

15.2.1 Select the OSPCM web site icon. 

1 5.2.2 View the web page contents. 

1 5.2.3 Exit web site and return to application. 

15.3 Select the Help Contents menu item from the Help menu. 
15.1.1 Select Search button and type "web" as the search 

word. 

15.1.2 Select the Show Topics button. 
15.1.3 Select a web jump topic. 
15.2 Double-click the web jump from the Help topic. 

15.2.1 View the web page contents. 

15.2.2 Exit the web site and return to the application. 



16. Attachments: 

(copies of screens, reports, 16.1 NONE 

etc. before and after 

proposed change-only 

identify if the customer 

requires the screen or 

something on the screen to 

look a certain way 



Signatures of Agreement: 

(add additional rows if necessary) 
BAE: 

Lead Analyst: 



(on file) 6/23/98 
(on file) 6/23/98 
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BAE FUNCTIONAL REQUIREMENT DOCUMENT 



Table # 7341 B 



BAE Start Date: 



04/07/1998 



BAE Name: 



Mark Seal 



BAE Comp. Date: 



04/15/1998 



BAE Tele. No.: 



205-977-3618 



BAE Hours: 



4 hours 



LA Assigned: 



CMVC Component Name: 



Scheduling 



Associated Defect/Feature No.: 



identify if this is required 
for an emergency release 
or must be worked in next 
scheduled release] 

Priority: 

(provide priority from 7 
'feature priority' list - 
number preliminary 
assigned by SME) 



Target Release: 

(give target release this 
needs to be in) [Only 



2.12 



Target Release Date: 

(give target release date for 
this enhancement, if required) 
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Revision No.: 
Reason for Revision: 



(B, C, etc. - this will require new signatures) 
B. . .Revised spec to delete the workstation changed because this 
functionality already exists in workstation. 



General: 

(General Information - 
nothing is to be typed here, 
this is for information only 
about the functional spec 
process) 



1 . The purpose of this document is to provide the customer's 
view of the functionality that needs to be changed or added to 
the existing OSPCM product. It is not the detail design 
requirements. It should concentrate on the 'what' that is 
needed and not on the 'how' it is provided. 

2. All features that are > 40 hours/ 1 business area require a structured 
inspection walk through process (currently using FAGAN). This is 
to be scheduled by the responsible SME for this feature with the 
testing team lead, documentation team lead and the IT development 
Managers. The IT develop managers will assign the appropriate 
representatives to attend the meeting. These inspections are not to 
inspect the author, they are to be used to understand the 
functionality required for development of the 'Detail Design 
Document'. 

3. The 'Analysis Phase Specific' checklist must be used, 
documented and baselined for each feature. 

4. Any correspondence associated with this feature should also 
be documented (i.e., impromptu meetings, phone 
conversations, etc.) and associated with the feature number. 
It should include time, date and participants. 

5. Continue numbering scheme in your text input under each to 
provide traceability for matrixes. 
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1. Abstract: 

(brief description of 1.1 Need to add ability to create and clear roadblocks on the 
change/addition) - This activity mtce screen in scheduling. 

should pretty closely match 1 .2 NOTE: This change will require less than 40 hours of work 
the abstract in CMVC. and therefore will not require a detail design document. 



2. Current Problem: 

(brief description of what 
system currently does, what 
needs to be changed, and 
why) 



2.1 User cannot create or clear roadblocks from 
the activity mtce screen in scheduling. . Screens are 
inconsistent. 



3. Proposed Solution: 

(brief description of what 
the system will or should do 
and any general constraints 
or conditions that limit the 
solution) 



3.1 Allow the user to create and clear roadblocks 
on the activity mtce screen in scheduling. Make 
the roadblock screen look and work the same in 
both scheduling and workstation. 



4. Change/Addition(s): 

(detailed description of 
change/addition) 



4.1 Scheduling module: 

Currently, on the activity mtce screen, if a roadblock exists 
on an activity and the user selects the activity and clicks on 
the roadblock button on the tool bar, then the roadblock 
screen is displayed with the roadblock data. Change the 
system so that the user can create or clear roadblocks on 
substeps. When a user selects a substep and clicks on the 
roadblock screen is displayed with any existing roadblock 
data. If there is no roadblock data then the screen will 



Exh. 2 -Page 190 



display with no data. The user will have the ability to create 
a roadblock or clear any existing roadblocks. This 
functionality exists in workstation today and can be used in 
the scheduling module. 



5, Performance Requirements: 

(list any performance 5.1 There should be no change in performance due to this 

requirements associated change. 

with this change) [Identify 

system response 

requirements that must be 

met for user acceptance] 



6. Dependencies: 

(list any defects or features 6.1 NONE 
that this enhancement is 
dependent on or that will be 
dependent on this feature) 
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7. Benefits: 

(provide benefits in dollars, 
reduced headcount, time 
savings, etc. for doing this 
work) [This is required to 
identify any savings that 
can be attributed this 
feature for securing 
budget approval] 

8. Affected Components: 

RTOC Instructions 

HELP X 

User Guides 

Testing 

Infra-structure 
Management Reports 
Database 

9. Interfaces: 

(list any legacy or new 9.1 NONE 

interface systems impacted 

by this change) [Make sure 

other interface systems are 

aware of and agree with 

any requirement change 

that impacts them before 

proceeding] 



7.1 This will allow the user responsible for 
scheduling to create, view and clear roadblocks 
when in the scheduling module. 



(check) (check) 

Yes No 



X 
X 
X 



X 
X 
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10. Work-around: (check) 

Yes 

(is there a temporary work 
around?) 

(describe work around in 
detail) [Also identify this in 
OSPCM 'known problem' 
document] 

11. Risks: 

(list factors that impact, 11.1 Users responsible for scheduling are not 

positive/negative, not doing creating roadblocks because it currently requires 

this change) that the scheduling module be closed and another 

module opened to create roadblocks. The 
schedule becomes inaccurate and roadblocked 
work is being scheduled incorrectly. 



(check) 
No 

X 



12. Business Rules: 

(list any business rules or 
constraints that should 
apply. If business rules are 
included in the changes 
section, identify these with 
asterisk in bold, 
***business rule***) 



12.1 Users should not be able to delete a roadblock. If a 
roadblock is entered in error then the user should clear the 
roadblock. 

12.2 When a substep is completed by the user and a roadblock 
exists on the substep then the system should clear the 
roadblock automatically. 
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13. Document Changes: 
(list affected documents 
requiring change) 
[Documentation should 
prepare a checklist 
covering each document 
that must be updated for 
this feature] 



13.1 Scheduling user guide 

13.2 Help for the activity mtce screen in the scheduling module. 



14. Special Training/Implementation Requirements: 

(list any special 14.1 NONE 

training/implementation 

required for this feature. 

Identify what will be 

required to train and 

implement this feature to 

the customer, i.e., by 

documentation, e-mail, 

help, cue cards, on sight 

training, etc.) 



15. Acceptance Criteria/Test Scenario: 

(list test scenarios required 15.1 Scheduling module 



to test change prior to user 
acceptance, this can be 
updated after the detailed 
design is completed.) 
REQUIRED [Tester 
should prepare checklist 
based on these test 
scenarios for 



Access the activity mtce screen for a job. 

Select a substep that has no existing roadblock and click the 

roadblock button. 

The roadblock screen should open. 

Add a roadblock to the substep and click OK 

Re-open the roadblock screen to verify that the new roadblock 

exists. 

Repeat this scenario creating and clearing critical and non- 
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documentation on results 
of tests. These should be 
in matrix form identified 
back to the numbering 
scheme used in these test 
scenarios] 



critical roadblocks. 

Verify that multiple roadblocks can be entered on a single 
substep 

Verify that when completing a substep in workstation or 
Billing and Reporting that the roadblocks are automatically 
cleared by the system. 



16. Attachments: 

(copies of screens, reports, 16.1 NONE 

etc. before and after 

proposed change-only 

identify if the customer 

requires the screen or 

something on the screen to 

look a certain way) 



Signatures of Agreement: 

(add additional rows if necessary) 
BAE: 

Lead Analyst: 
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BAE FUNCTIONAL REQUIREMENT DOCUMENT 



Table # 7342a 



BAE Start Date: 



04/08/1998 



BAE Name: 



Mark Seal 



BAE Comp. Date: 



04/08/1998 



BAE Tele. No.: 



205-977-3618 



BAE Hours: 



3 



LA Assigned: 



CMVC Component Name: 



Scheduling 



Associated Defect/Feature No.: 



identify if this is required 
for an emergency release 
or must be worked in next 
scheduled release] 

Priority: 

(provide priority from HIGH 
'feature priority' list - 
number preliminary 
assigned by SME) 



Target Release: 

(give target release this 
needs to be in) [Only 



2.15 



Target Release Date: 

(give target release date for 
this enhancement, if required) 
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Revision No.: 
Reason for Revision: 



(B, C, etc. - this will require new signatures) 



General: 

(General Information - 
nothing is to be typed here, 
this is for information only 
about the functional spec 
process) 



1 . The purpose of this document is to provide the customer's 
view of the functionality that needs to be changed or added to 
the existing OSPCM product. It is not the detail design 
requirements. It should concentrate on the 'what' that is 
needed and not on the 'how' it is provided. 

2. All features that are > 40 hours/1 business area require a structured 
inspection walk through process (currently using FAGAN). This is 
to be scheduled by the responsible SME for this feature with the 
testing team lead, documentation team lead and the IT development 
Managers. The IT develop managers will assign the appropriate 
representatives to attend the meeting. These inspections are not to 
inspect the author, they are to be used to understand the 
functionality required for development of the 'Detail Design 
Document'. 

3. The 'Analysis Phase Specific' checklist must be used, 
documented and baselined for each feature. 

4. Any correspondence associated with this feature should also 
be documented (i.e., impromptu meetings, phone 
conversations, etc.) and associated with the feature number. 
It should include time, date and participants. 

5. Continue numbering scheme in your text input under each to 
provide traceability for matrixes. 
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1. Abstract: 

(brief description of 1.1 Allow the user to request, display and print the scheduling 

change/addition) - This diagnostic report for a single job. 

should pretty closely match 
the abstract in CMVC. 



2. Current Problem: 

(brief description of what 
system currently does, what 
needs to be changed, and 
why) 



2.1 Currently to check the scheduling diagnostic 
report to determine why an activity was delayed or 
did not schedule at all, the user must request the 
entire report which is for every job in the 
scheduling area. 



3. Proposed Solution: 

(brief description of what 
the system will or should do 
and any general constraints 
or conditions that limit the 
solution) 

4. Change/ Addition(s): 

(detailed description of 4.1 When the user selects the Scheduling diagnostic report from 

change/addition) the print or print preview buttons, the system will display a 

dialog box. The user will have the option to select "ALL" or 

enter a job name in the dialog box. 

4.2 When the user enters a job name and if the scheduling 
process generated data for the scheduling diagnostic report 
then only that job name will be on the report. 

4.3 If the job name is not on the report then a message should be 
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3.1 Allow the user to request, display and print 
the scheduling diagnostic report for a single job. 



displayed that says that the job is not on the scheduling 
diagnostic report. 
4.4 When the user selects "ALL" from the dialog box then the 
entire report will be displayed or printed appropriately. 



5. Performance Requirements: 

(list any performance 5. 1 There should be no change in system performance due to 

requirements associated this feature. 

with this change) [Identify 

system response 

requirements that must be 

met for user acceptance] 



6. Dependencies 

(list any defects or features 6.1 NONE 
that this enhancement is 
dependent on or that will be 
dependent on this feature) 



7. Benefits: 

(provide benefits in dollars, 7.1 This will save the user time when investigating only one job. 
reduced headcount, time This will also reduce system processing time to retrieve and 

savings, etc. for doing this display the entire report, 

work) [This is required to 
identify any savings that 
can be attributed this 
feature for securing 
budget approval] 
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8. Affected Components: 

RTOC Instructions 
HELP 
User Guides 
Testing 

Infra-structure 
Management Reports 
Database 



X 



(check) 
Yes 



No 



X 
X 



(check) 



X 
X 
X 



9. Interfaces: 
(list any legacy or new 
interface systems impacted 
by this change) [Make sure 
other interface systems are 
aware of and agree with 
any requirement change 
that impacts them before 
proceeding] 



9.1 NONE 



10. Work-around: 

(is there a temporary work 
around?) 

(describe work around in 
detail) [Also identify this in 
OSPCM 'known problem' 
document] 



(check) 
Yes 



(check) 
No 
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11. Risks: 

(list factors that impact, 11.1 If this change is not implemented the user 

positive/negative, not doing will continue to spend time going through the 

this change) entire report instead of only one job. 



12. Business Rules: 

(list any business rules or 
constraints that should 
apply. If business rules are 
included in the changes 
section, identify these with 
asterisk in bold, 
***business rule***) 



12.1 Job number is actually job name. 

12.2 Job name must have information on the report. 

12.3 When the user selects "ALL" from the dialog box then the 
entire report will be displayed or printed appropriately. 

12.4 Only job names that existed when the last schedule run took 
place will be on the diagnostic report. 
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13. Document Changes: 

(list affected documents 13.1 Scheduling user guides and help. 

requiring change) 

[Documentation should 

prepare a checklist 

covering each document 

that must be updated for 

this feature] 

14. Special Training/Implementation Requirements: 

(list any special 14.1 NONE 

training/implementation 

required for this feature. 

Identify what will be 

required to train and 

implement this feature to the 

customer, i.e., by 

documentation, e-mail, help, 

cue cards, on sight training, 

etc.) 



15. Acceptance Criteria/Test Scenario: 


(list test scenarios required 


15.1 


to test change prior to user 


• 


Go to the scheduling desk top 


acceptance, this can be 


• 


Click on the print report button on the tool bar 


updated after the detailed 


• 


The report menu should display 


design is completed.) 


• 


Select the scheduling diagnostic report 


REOUIRED [Tester 


• 


A dialog box should be displayed 


should prepare checklist 


• 


Enter a valid job name for a job that should be on the report 


based on these test 




and click OK 


scenarios for 


• 


The report should print with only the information for the job 
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documentation on results 



name entered 



of tests. These should be 



15.2 



in matrix form identified 



Go to the scheduling desk top 

Click on the print report button on the tool bar 



back to the numbering 



scheme used in these test 



The report menu should display 
Select the scheduling diagnostic report 
A dialog box should be displayed 



scenarios] 



Select "ALL" click OK 



The entire scheduling diagnostic report should print 



15.3 



• Go to the scheduling desk top 

• Click on the print report button on the tool bar 

• The report menu should display 

• Select the scheduling diagnostic report 

• A dialog box should be displayed 

• Enter a valid job name for a job that should NOT be on the 
report 

• A message should display saying that this job number is not 
on the scheduling diagnostic report. 



• Go to the scheduling desk top 

• Click on the print preview button on the tool bar 

• The report menu should display 

• Select the scheduling diagnostic report 

• A dialog box should be displayed 

• Enter a valid job name for a job that should be on the report 
and click OK 

• The report should display with only the information for the 
job name entered 



15.4 
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15.5 

• Go to the scheduling desk top 

• Click on the print preview button on the tool bar 

• The report menu should display 

• Select the scheduling diagnostic report 

• A dialog box should be displayed 

• Select "ALL" and click OK 

• The entire scheduling diagnostic report should display. 
15.6 

• Go to the scheduling desk top 

• Click on the print preview button on the tool bar 

• The report menu should display 

• Select the scheduling diagnostic report 

• A dialog box should be displayed 

• Enter a valid job name for a job that should NOT be on the 
report 

• A message should display saying that this job is not on the 
scheduling diagnostic report. 

15.7 

• Go to job entry and change the name of a job that should be 
on the scheduling diagnostic report and save 

• Go to the scheduling desk top 

• Click on the print preview button on the tool bar 

• The report menu should display 

• Select the scheduling diagnostic report 

• A dialog box should be displayed 

• Enter the new job name for the job changed in job entry 

• A message should display saying that this job is not on the 
scheduling diagnostic report 

• NOTE: Only job names that existed when the last schedule 
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run took place will be on the diagnostic report 
15.8 

• Go to the scheduling desk top 

• Click on the print button on the tool bar 

• The report menu should display 

• Select the scheduling diagnostic report 

• A dialog box should be displayed 

• Enter the new job name for the job changed in job entry 

• A message should display saying that this job is not on the 
scheduling diagnostic report 

• NOTE: Only job names that existed when the last schedule 
run took place will be on the diagnostic report 

16. Attachments: 

(copies of screens, reports, 16.1 NONE 

etc. before and after 

proposed change-only 

identify if the customer 

requires the screen or 

something on the screen to 

look a certain way) 



t. 
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Signatures of Agreement: 

(add additional rows if necessary) 

BAE: (on file) 5/14/98 

Lead Analyst: (on file) 5/14/98 



i 
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BAE FUNCTIONAL REQUIREMENT DOCUMENT 



Table # 7376B 



BAE Start Date: 



December 8, 1997 



BAE Name: 



Carol A. Brechtel 



BAE Comp. Date: 



February 24, 1998 



BAE Tele. No.: 



205-977-3611 



BAE Hours: 



2.5 hours 



LA Assigned: 



CMVC Component Name: 



MATMGMT 



Associated Defect/Feature No.: 



None 



Target Release: 

(give target release this 
needs to be in) [Only 



Target Release Date: 

(give target release date for 
this enhancement, if required) 



identify if this is required 
for an emergency release 
or must be worked in next 
scheduled release] 

Priority: 

(provide priority from Priority XX 

'feature priority' list - 
number preliminary 
assigned by SME) 
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Revision No.: 
Reason for Revision: 



7376B (B, C, etc. - this will require new signatures) 

The Due Date should only default to blanks/nulls if the system 

generated due date is less than tomorrow or blank. 



General: 

(General Information - 
nothing is to be typed here, 
this is for information only 
about the functional spec 
process) 



1 . The purpose of this document is to provide the customer's 
view of the functionality that needs to be changed or added to 
the existing OSPCM product. It is not the detail design 
requirements. It should concentrate on the 'what' that is 
needed and not on the 'how' it is provided. 

2. All features that are > 40 hours/ 1 business area require a structured 
inspection walk through process (currently using FAGAN). This is 
to be scheduled by the responsible SME for this feature with the 
testing team lead, documentation team lead and the IT development 
Managers. The IT develop managers will assign the appropriate 
representatives to attend the meeting. These inspections are not to 
inspect the author, they are to be used to understand the 
functionality required for development of the 'Detail Design 
Document'. 

3. The 'Analysis Phase Specific' checklist must be used, 
documented and baselined for each feature. 

4. Any correspondence associated with this feature should also 
be documented (i.e., impromptu meetings, phone 
conversations, etc.) and associated with the feature number. 
It should include time, date and participants. 

5. Continue numbering scheme in your text input under each to 
provide traceability for matrixes. 
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1. Abstract: 

(brief description of 
change/addition) - This 
should pretty closely match 
the abstract in CMVC. 



1 . 1 Allow the user to change the Due Date on an 
order on the "Generate Order for Job XXX" main 
window. 

1 .2 Hide/Remove the Due Date on the Order 
Option Tab 

1 .3 Default the Due Date field to nulls/blanks if 
the system generated Due Date is less than or 
equal to tomorrow; otherwise use the calculated 
date. 

1 .4 Due Date field is a required field - require the 
user to populate the field before sending the order 
to OrderMaster. 



2. Current Problem: 

(brief description of what 
system currently does, what 
needs to be changed, and 
why) 



2. 1 To change the Due Date on an order the user 
must select the Order Options Tab on the 
"Generate Order for Job XX" window and make 
the date change on the tab. The user would like 
the capability to change the Due Date on the main 
window. 

2.2 The due date defaults to the date generated 
when the job was scheduled. If the date is blank 
the due date defaults to today + one day. The 
system should be enhanced to require the user to 
enter a due date if the system generated Due Date 
is less than or equal to tomorrow; otherwise use 
the calculated due date. If the system generated 
Due Date is greater than tomorrow populate the 
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Due Date field with that date. 

2.3 The due date field should be a required field 

before the order can be sent to OrderMaster 
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3. Proposed Solution: 

(brief description of what 
the system will or should do 
and any general constraints 
or conditions that limit the 
solution) 



3.1 Require the user to enter the Due Date on the header of the 
"Generate Order for Job XX" window, this is a display only field 
now. 

3.2 Remove the note next to the Due Date field on 
the main window. 

3.3 Default the Due Date to nulls/blanks if the 
system generated Due Date is less than or equal to 
tomorrow; otherwise use the calculated due date. 

3.4 Due Date field - required field before sending 
the order to OrderMaster. 



4. Change/ Addition(s): 

(detailed description of 4.1 Change the Due Date display field on the 

change/addition) header section of the "Generate Order for Job XX" 

window, to a field that can be updated. 

4.2 Remove the note next to the Due Date field on 
the main window. 

4.3 Remove or hide the Due Date field on the 
Order Option Tab. 

4.4 Default the Due Date field to nulls/blanks if 
the system generated Due Date field is less than or 
equal to tomorrow; otherwise use the calculated 
due date. 

4.5 Due Date is required field before the Order 
can be sent to OrderMaster. 
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5. Performance Requirements: 

(list any performance 5.1 There should be no noticeable affect on performance. 

requirements associated 

with this change) [Identify 

system response 

requirements that must be 

met for user acceptance] 

6. Dependencies: 

(list any defects or features 6.1 NONE 
that this enhancement is 
dependent on or that will be 
dependent on this feature) 

7. Benefits: 

(provide benefits in dollars, 
reduced headcount, time 
savings, etc. for doing this 
work) [This is required to 
identify any savings that 
can be attributed to this 
feature for securing 
budget approval] 



7.1 Allow the user to change the due date without 
going to the Order Option Tab - more user 
friendly. 

7.2 Most users forget to select the order Option 
tab, therefore, the due date doesn't get changed. 
Order is sent as rushed when it really isn't a rush 
job. 
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8. Affected Components: 

RTOC Instructions 
HELP 
User Guides 
Testing 

Infra-structure 
Management Reports 
Database 

9. Interfaces: 

(list any legacy or new 
interface systems impacted 
by this change) [Make sure 
other interface systems are 
aware of and agree with 
any requirement change 
that impacts them before 
proceeding] 

Work-around: 

(is there a temporary work 
around?) 

(describe work around in 
detail) [Also identify this in 
the OSPCM 'known 
problem' document] 



(check) (check) 
Yes No 

X 

X 

X 
X 

X 
X 



9.1 NONE 



(check) (check) 
Yes No 

X 

10.1 The user must select the Order 
Options Tab & change the due 
date before sending the order to 
OrderMaster. 
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11. Risks: 

(list factors that impact, 11.1 Order will be created with the wrong due 

positive/negative, not doing date. 

this change) 1 1 .2 Creating rush orders when they really aren't 

rush. 



12. Business Rules: 

(list any business rules or 
constraints that should 
apply. If business rules are 
included in the changes 
section, identify these with 
asterisk in bold, 
***business rule***) 



12. 1 Same rules that exist today when creating an order. 

12.2 The user must enter a future day (due date must be greater 
than today) 



13. Document Changes: 
(list affected documents 
requiring change) 
[Documentation should 
prepare a checklist 
covering each document 
that must be updated for 
this feature] 



13.1 Functional Decomps 

13.2 Test Scenarios 

13.3 Materials Management Business Solution(s) 

13.4 Materials Management User Guide 

13.5 Help 
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14. Special Training/Implementation Requirements: 

(list any special 14.1 NONE 

training/implementation 

required for this feature. 

Identify what will be 

required to train and 

implement this feature to the 

customer, i.e., by 

documentation, e-mail, help, 

cue cards, on sight training, 

etc.) 



15. Acceptance Criteria/Test Scenario: 

(list test scenarios required First Test : 



to test change prior to user 
acceptance, this can be 
updated after the detailed 
design is completed.) 
REQUIRED [Tester 
should prepare checklist 
based on these test 
scenarios for 
documentation on results 
of tests. These should be 
in matrix form identified 
back to the numbering 
scheme used in these test 
scenarios] 



15.1 Encode a job in Job Entry 

15.2 Configure, price and firm the job 

1 5.3 Select the job in Materials Management - "Needed 
Requirements for Job XX" window 

15.4 Select one or more requirement and select the Create Order 
Toolbar button. 

1 5.5 Change or enter the Order Due date on the "Generate Order 
for Job XX" main window. 

Second Test : 

Complete steps 15.1 to 15.4 a second time, select 
the send order to Order Master button, the system 
should generate an error message letting the user 
know that the Due Date is a required field. 
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16. Attachments: 

(copies of screens, reports, 
etc. before and after 
proposed change-only 
identify if the customer 
requires the screen or 
something on the screen to 
look a certain way) 

Signatures of Agreement: 

(add additional rows if necessary) 
BAE: 

Lead Analyst: 

Allow the user to change the Due Date on the header of the main window. Remove the note "To 
change the Due Date select the Order Option tab". 



16.1 Fig. 10 is an exemplary screen print for OSPCM Material 
0.97d. 
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BAE FUNCTIONAL REQUIREMENT DOCUMENT 



Table # 7380A 



BAE Start Date: 
BAE Comp. Date: 
BAE Hours: 



December 10, 1997 
December 18, 1997 
2 Hours 



BAE Name: 
BAE Tele, No.: 
LA Assigned: 



Carol A. Brechtel 
205-977-3611 
Jeff Elder 



CMVC Component Name: 



CORE TABLES LOC EDIT 



Associated Defect/Feature No.: 



NONE 



Target Release: 
(give target release this 
needs to be in) [Only 
identify if this is required 
for an emergency release 
or must be worked in next 
scheduled release] 



Target Release Date: 

(give target release date for 
this enhancement, if required) 



Priority: 

(provide priority from 
'feature priority' list - 
number preliminary 
assigned by SME) 
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Revision No.: 
Reason for Revision: 



(B, C, etc. - this will require new signatures) 



General: 

(General Information - 
nothing is to be typed here, 
this is for information only 
about the functional spec 
process) 



1 . The purpose of this document is to provide the customer's 
view of the functionality that needs to be changed or added to 
the existing OSPCM product. It is not the detail design 
requirements. It should concentrate on the 'what' that is 
needed and not on the 'how' it is provided. 

2. All features that are > 40 hours/ 1 business area require a structured 
inspection walk through process (currently using FAG AN). This is 
to be scheduled by the responsible SME for this feature with the 
testing team lead, documentation team lead and the IT development 
Managers. The IT develop managers will assign the appropriate 
representatives to attend the meeting. These inspections are not to 
inspect the author, they are to be used to understand the 
functionality required for development of the 'Detail Design 
Document'. 

3. The 'Analysis Phase Specific' checklist must be used, 
documented and baselined for each feature. 

4. Any correspondence associated with this feature should also 
be documented (i.e., impromptu meetings, phone 
conversations, etc.) and associated with the feature number. 
It should include time, date and participants. 

5. Continue numbering scheme in your text input under each to 
provide traceability for matrixes. 
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1. Abstract: 

(brief description of 
change/addition) - This 
should pretty closely match 
the abstract in CMVC. 



1 . 1 The user should not be allowed to end date or 
delete an inventory site that has inventory assigned 
to it or that is used anywhere in OSPCM (example: 
inventory site is on an open order) 

1 .2 The user should not be allowed to end date or 
delete a wire center if it is being used somewhere 
else in OSPCM (configuration tables, encoded on 
open substeps on open jobs, etc.) 

1 .3 The user should not be allowed to end date 
or delete a CMC if inventory sites or wire centers 
are still associated with the CMC. Also, if the 
CMC is being used some where else in OCPCM 
(open complaints, open jobs, etc.) the user should 
not be allowed to end date or delete the CMC. 



2. Current Problem: 

(brief description of what 
system currently does, what 
needs to be changed, and 
why) 



2.1 Today an inventory site can be end dated or 
deleted when inventory still resides at the 
locations. Enhance the system to not allow the 
user to end date or delete an inventory site with 
existing inventory, generate an error message 
letting the user know that inventory still exists at 
the location. Also if the inventory site is assigned 
to an open order the user should not be allowed to 
end date or delete the inventory site, system should 
generate error message. 

2.2 Today a wire center can be end dated or 
deleted when open jobs exist for the wire center. 
Enhance the system to only allow the user to end 
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date or delete a wire center only if the wire center 
is not used on any open substep (jobs) within 
OSPCM. (Not only jobs but complaints, exhibit C 
of the contract, etc.) The system should generate 
an error message letting the user know that the 
wire center is being used in OSPCM. 
2.3 Today a CMC can be deleted or end dated 
even if inventory sites or wire centers are 
associated to the CMC. The system should 
generate an error message letting the user know 
that they can not delete or end date the CMC until 
all inventory sites and wire centers have either 
been moved to another CMC, have been end dated 
or deleted. 



3. Proposed Solution: 

(brief description of what 
the system will or should do 
and any general constraints 
or conditions that limit the 
solution) 



3.1 If inventory still exists at an inventory site or if the inventory 
site is associated with configuration tables or open orders the 
system should generate an error message letting the user 
know that the inventory site can not be end dated or deleted. 

3.2 If a wire center is associated with an open job (all types), 
configuration table, valid contract, complaints, or inspection 
the system should generate an error message letting the user 
know that the wire center can not be end dated or deleted. 
Also if a wire center is not being used in OSPCM the system 
should generate a warning message to let the user know that 
they may need to update LMOS, since when a wire center is 
end dated or deleted it also effects the associated LMOS and 
OSPCM in sync. 
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3.3 If a CMC still has inventory sites or wire centers associated 
with it the system should generate an error message letting 
the user know that the CMC can not be end dated or deleted, 
because wire centers or inventory sties still exist for the 
CMC. 

3.4 The inventory site is associated to the master contract as a 
supply center and can not be validated until moved to 
informix data base. 



4. Change/Addition(s): 

(detailed description of 
change/addition) 



4.1 Add additional edits to the OSPCM Location 
Editor when the user attempted to delete or end 
date a CMC, wire center or inventory site. The 
edits should not allow locations of any type to be 
deleted or end dated if the locations are being used 
by any OSPCM executable, (job entry, 
configuration tables, job entry-other, materials 
management, etc.) 

4.2 Make sure that hard deletes are only 
performed when there are no associated records. 



5. Performance Requirements: 



(list any performance 
requirements associated 
with this change) [Identify 
system response 
requirements that must be 
met for user acceptance] 



5.1 There should be no noticeable affect on performance. 

NOTE: Due to the number of tables to check there may be a 
performance problem, need to look at the best way to handle all 
edits without causing a performance problem. 
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6. Dependencies: 

(list any defects or features 
that this enhancement is 
dependent on or that will be 
dependent on this feature) 

7. Benefits: 

(provide benefits in dollars, 
reduced headcount, time 
savings, etc. for doing this 
work) [This is required to 
identify any savings that 
can be attributed to this 
feature for securing budget 
approval] 

8. Affected Components: 

RTOC Instructions 
HELP 
User Guides 
Testing 

Infra-structure 
Management Reports 
Database 



6.1 NONE 



7.1 Existing inventory will not be available for the user if the 
inventory site is end dated or deleted. 

7.2 Jobs that are encoded with the end dated or deleted wire 
center will not work properly. 

7.3 If a CMC is end dated or deleted all location associated 
with it (inventory sites and wire centers) will not be good 
in OSPCM. 



(check) (check) 
Yes No 



X 



X 



X 
X 
X 
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9. Interfaces 

(list any legacy or new 9.1 NONE 

interface systems impacted 

by this change) [Make sure 

other interface systems are 

aware of and agree with 

any requirement change 

that impacts them before 

proceeding] 



10. Work-around: (check) (check) 

Yes No 

(is there a temporary work X 
around?) 

(describe work around in 
detail) [Also identify this in 
the OSPCM 'known 
problem 9 document] 



11. Risks: 

(list factors that impact, 
positive/negative, not doing 
this change) 



11.1 OSPCM Data Bases may be out of sync. 

1 1 .2 Lost of data & inventory 

11.3 We will have a very messed up system. 



12. Business Rules: 

(list any business rules or 
constraints that should apply. 
If business rules are included 
in the changes section, 
identify these with asterisk is 
bold, ***business rule***) 



12.1 Locations (CMC, Inventory Sites and Wire Centers) in 
OSPCM should not be end dated or deleted if they are 
being used by any execuin OSPCM. Examples: 
inventory still assigned to an inventory site, open order 
being shipped to the inventory site, wire centers that are 
encoded on open substeps (all jobs: EW, BSW, RW, 
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PWO, etc.), or that exist on a valid contract, CMC that 
are valid on open jobs or that still have inventory sites 
and wire centers associated with them. 



13. Documentation Changes: 
(list affected documents 
requiring change) 
[Documentation should 
prepare a checklist covering 
each document that must be 
updated for this feature] 



13.1 Functional Decomps 

13.2 Test Scenario 

13.3 Help 



14. Special Training/Implementation Requirements: 

(list any special 14.1 NONE 

training/implementation 

required for this feature. 

Identify what will be required 

to train and implement this 

feature to the customer, i.e., 

by documentation, e-mail, 

help, cue cards, on sight 

training etc.) 

15. Acceptance Criteria/Test Scenario: 

(list test scenarios required to 15.1 Open the Location Editor 

test change prior to user 15.2 Attempt to end date a CMC with associated inventory 

acceptance, this can be sites and/or wire centers. 

updated after the detailed 15.3 Attempt to end date an inventory site that still has 

design is completed.) inventory assigned to the site. 

REQUIRED [Tester should 15.4 Attempt to end date a wire center that is valid on an open 
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prepare checklist based on 
these test scenarios for 
documentation on results of 
tests. These should be in 
matrix form identified back 
to the numbering scheme 
used in these test scenarios] 



substep/job. 

15.5 Complete the above test again attempting to delete the 
CMC, inventory site and wire center. 

15.6 Attempt to end date a location that has only historical 
records associated to it. 

NOTE: Test both future day and current end dates. 



16. Attachments: 

(copies of screens, reports, 16.1 NONE 
etc. before and after proposed 
change-only identify if the 
customer requires the screen 
or something on the screen to 
look a certain way) 



Signatures of Agreement: 

(add additional rows if necessary) 
BAE: 

Lead Analyst: 
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BAE FUNCTIONAL REQUIREMENT DOCUMENT 



Table # 7420A 



BAE Start Date: 05/13/1998 
BAE Comp. Date: 05/13/1998 
BAE Hours: 4 



BAE Name: 
BAE Tele. No. 
LA Assigned: 



Gail Deaton 
977-3615 



CMVC Component Name: 



Je ewo 



Associated Defect/Feature No. 



6424 



Target Release: 

(give target release this 
needs to be in) 



2.15 



Target Release Date: 

(give target release 8/98 
date for this 
enhancement) 



Priority: 

(provide priority from 
'feature priority' list - 
production Jii through 
deferred_low) 



Production hi 



Revision No.: 
Reason for Revision: 
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General: 

(General Information - 
nothing is to be typed here, 
this is for information only 
about the functional spec 
process) 



1 . The purpose of this document is to provide the customer's 
view of the functionality that needs to be changed or added to 
the existing OSPCM product. It is not the detail design 
requirements. It should concentrate on the 'what' that is 
needed and not on the 'how' it is provided. 

2. All features that are > 40 hours/1 business area require a structured 
inspection walk through process (currently using FAGAN). This is 
to be scheduled by the responsible SME for this feature with the 
testing team lead, documentation team lead and the IT development 
Managers. The IT develop managers will assign the appropriate 
representatives to attend the meeting. These inspections are not to 
inspect the author, they are to be used to understand the 
functionality required for development of the 'Detail Design 
Document'. 

3. The 'Analysis Phase Specific' checklist must be used, 
documented and baselined for each feature. 

4. Any correspondence associated with this feature should also 
be documented (i.e., impromptu meetings, phone 
conversations, etc.) and associated with the feature number. 
It should include time, date and participants. 

5. Continue numbering scheme in your text input under each to 
provide traceability for matrixes. 
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1. Abstract: 

(brief description of 1.1 Add an OSPCM generated report for Contract-Move errors 

change/addition) - This generated by the Contract Move process in F6424 

should pretty closely match 
the abstract in CMVC. 



2. Current Problem: 

(brief description of what 
system currently does, what 
needs to be changed, and 
why) 

document and then e-mails to the user that 
requested the move. 



2.1 No mechanized report exists to notify the 
user of errors that were generated during the 
Contract Move process. Currently a programmer 
receives the errors, reformats into a Word 



3. Proposed Solution: 

(brief description of what 
the system will or should do 
and any general constraints 
or conditions that limit the 
solution) 



3.1 Create a mechanized report for the errors 
generated from the batch Contract Move process. 
Create an ICON on the Contract Move screen to 
access Contract Move Results. 



4. Change/Addition(s): 

(detailed description of 
change/addition) 



4. 1 Create a mechanized report for the errors generated from the 
batch Contract Move process. Create an ICON on the 
Contract Move screen to access Contract Move Results. 
Display a list of contract moves for the user to select from, 
[from MTN512 to MTN598 process date 05/1 1/1998] Have 
the user select from a list by double clicking. See attachment 
for report layout. 
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5. Performance Requirements: 



List any performance 
requirements associated 
with this change) [Identify 
system response 
requirements that must be 
met for user acceptance] 



5.1 Performance should not be affected. 



6. Dependencies: 

(list any defects or features 
that this enhancement is 
dependent on or that will be 
dependent on this feature) 



6.1 Completion of F6424 



7. Benefits: 

(provide benefits in dollars, 
reduced headcount, time 
savings, etc. for doing this 
work) [This is required to 
identify any savings that 
can be attributed to this 
feature for securing budget 
approval] 



7.1 Takes the programmer out of the loop in the Contract Move 
process which will result in a time and dollar savings. Also 
gives any user in the CMC the ability to pull and view the 
Contract Move Results. 



8. Affected Components: (check) (check) 

Yes No 

RTOC Instructions 
HELP 

User Guides X 
Testing 
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Infra-structure 
Management Reports 
Database 

9. Interfaces 

(list any legacy or new 
interface systems impacted by 
this change) [Make sure 
other interface systems are 
aware of and agree with any 
requirement change that 
impacts them before 
proceeding] 

10. Work-around: (check) (check) 



Yes 



No 



(is there a temporary work 
around?) 

(describe work around in 
detail) [Also identify this in 



programmer check the servers 
each night for a batch Contract 
Move and then generate the 
error reports, reformat the 
report into a Word document 
and email to the user who 



10.1 Continue to have a 



the OSPCM 'known 



problem' document] 



requested the move. 



11. Risks: 



(list factors that impact, 
positive/negative, not doing 
this change) 



11.1 Loss of experienced programmer to perform this process 
and field user acceptability of the Contract Move 



process. 
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12. Business Rules: 

(list any business rules or 
constraints that should apply. If 
business rules are included in 
the changes section, identify 
these with asterisk in bold, 
***business rule***) 

13. Documentation Changes: 

(list affected documents 13.1 User Guides and On-Line Help 

requiring change) 

[Documentation should prepare a 

checklist covering each 

document that must be updated 

for this feature] 

14. Special Training/Implementation Requirements: 

(list any special 

training/implementation required 
for this feature. Identify what 
will be required to train and 
implement this feature to the 
customer, i.e., by documentation, 
e-mail, help, cue cards, on sight 
training, etc.) 
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15. Acceptance Criteria/Test Scenario: 



(list test scenarios required to test 
change prior to user acceptance. 
This can be updated after the 
detailed design is completed.) 
REQUIRED [Tester should 
prepare checklist based on these 
test scenarios for documentation 
on results of tests. These should 
be in matrix form identified 
back to the numbering scheme 
used in these test scenarios] 



15.1 Run a Contract Move process. 

Go to JE-EWO and to the Move Contract icon. 

Verify that an icon exists for Contract Move Results. 

Request report 

Print report 

Verify that the report contains all fields specified. 
Verify that the report data is formatted correctly. 
Verify that the data generated is correct. 
Verify that all data is generated from the Move process. 



16. Attachments: 

(copies of screens, reports, etc. 
before and after proposed change- 
only identify if the customer 
requires the screen or something 
on the screen to look a certain 
way) 



16.1 Report layout 



Signatures of Agreement: 

(add additional rows if necessary) 
BAE: 

Lead Analyst: 
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BAE FUNCTIONAL REQUIREMENT DOCUMENT 



Table # 7420B 



BAE Start Date: 



05/13/1998 



BAE Name: 



Gail Deaton 



BAE Comp. Date: 



06/05/1998 



BAE Tele. No.: 



977-3615 



BAE Hours: 



6 



LA Assigned: 



CMVC Component Name: 



je_ewo 



Associated Defect/Feature No.: 



6424 



Target Release: 

(give target release this 
needs to be in) [Only 



2.15 



Target Release Date: 

(give target release date for 
this enhancement, if required) 



8/98 



identify if this is required 
for an emergency release 
or must be worked in next 
scheduled release] 

Priority: 

(provide priority from production_hi 
'feature priority' list - 
number preliminary 
assigned by SME) 
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Revision No.: 
Reason for Revision: 



(B, C, etc. - this will require new signatures) 



General: 

(General Information - 
nothing is to be typed here, 
this is for information only 
about the functional spec 
process) 



1 . The purpose of this document is to provide the customer's 
view of the functionality that needs to be changed or added to 
the existing OSPCM product. It is not the detail design 
requirements. It should concentrate on the 'what' that is 
needed and not on the 'how' it is provided. 

2. All features that are > 40 hours/ 1 business area require a structured 
inspection walk through process (currently using FAGAN). This is 
to be scheduled by the responsible SME for this feature with the 
testing team lead, documentation team lead and the IT development 
Managers. The IT develop managers will assign the appropriate 
representatives to attend the meeting. These inspections are not to 
inspect the author, they are to be used to understand the 
functionality required for development of the 'Detail Design 
Document'. 

3. The 'Analysis Phase Specific' checklist must be used, 
documented and baselined for each feature. 

4. Any correspondence associated with this feature should also 
be documented (i.e., impromptu meetings, phone 
conversations, etc.) and associated with the feature number. 
It should include time, date and participants. 

5. Continue numbering scheme in your text input under each to 
provide traceability for matrixes. 
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1. Abstract: 

(brief description of 
change/addition) - This 
should pretty closely match 
the abstract in CMVC. 



1.1 Add an OSPCM generated report for 
Contract-Move errors generated by the Contract 
Move process in F6424. 



2. Current Problem: 

(brief description of what 
system currently does, what 
needs to be changed, and 
why) 



2.1 Feature 6424 provides an email of the errors 
for each job that failed preconfiguration and 
configuration. Using this method, the user who 
requests the Contract Move could be deluged with 
individual job error messages. In addition, if the 
user who requests the move does not have an 
established email address, the errors are not sent. 



3. Proposed Solution: 

(brief description of what 
the system will or should do 
and any general constraints 
or conditions that limit the 
solution) 



3 . 1 Create a mechanized report for the errors 
generated from the batch Contract Move process. 
Create an ICON on the Contract Move screen to 
access Contract Move Results. 



4. Change/Addition(s): 

(detailed description of 
change/addition) 



4. 1 Create a mechanized report for the errors 
generated from the batch Contract Move process. 

4.1.1 Create an ICON on the Contract Move 
screen to access Contract Move Results. 

4.1 .2 Display a list of contract moves for the user 
to select from [from MTN512 to MTN598 process 
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date 05/11/1998] 

4.1 .3 Have the user select from a list by double 
clicking 

4.1.4 Positive reporting should be indicated for 
each successful run. 

4.1 .5 Store results for each run and then purge 
after 30 days. 

4.1 .6 For jobs that fail to process, update the batch 
processing run date to the next day. 

4.1 .7 Eliminate the emailing of errors established 
by Feature 6424. 

See attachment for report layout. 

5. Performance Requirements: 

(list any performance 5.1 Performance should not be affected. 

requirements associated 

with this change) [Identify 

system response 

requirements that must be 

met for user acceptance] 
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6. Dependencies: 

(list any defects or features 
that this enhancement is 
dependent on or that will be 
dependent on this feature) 

7. Benefits: 

(provide benefits in dollars, 
reduced headcount, time 
savings, etc. for doing this 
work) [This is required to 
identify any savings that can 
be attributed to this feature 
for securing budget 
approval] 

8. Affected Components: 

RTOC Instructions 
HELP 
User Guides 
Testing 

Infra-structure 
Management Reports 
Database 



6.1 Completion of F6424 



7.1 Gives any user in the CMC the ability to pull and view the 
Contract Move Results. Eliminates emailing of errors. 



(check) (check) 
Yes No 

X 

X 
X 
X 

X 
X 

X 

i 
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9. Interfaces 

(list any legacy or new 
interface systems impacted 
by this change) [Make sure 
other interface systems are 
aware of and agree with 
any requirement change 
that impacts them before 
proceeding] 

10. Work-around: 

(is there a temporary work 
around?) 

(describe work around in 
detail) [Also identify this in 
the OSPCM 'known 
problem' document] 

11. Risks: 

(list factors that impact, 
positive/negative, not doing 
this change) 



9.1 NONE 



(check) (check) 
Yes No 
X 



10.1 Email process of 
notification will continue. 



11.1 If no email address exists for the cuid requesting the 
Move, no error messages can be retrieved. Only the 
person who requests the Move has access to the errors. 
Possibility of a deluge of emails. 
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12. Business Rules: 

(list any business rules or 12.1 NONE 

constraints that should apply. 

If business rules are included 

in the changes section, identify 

these with asterisk is bold, 

***business rule***) 

13. Documentation Changes: 

(list affected documents 13.1 User Guides and On-Line Help 

requiring change) 

[Documentation should 

prepare a checklist covering 

each document that must be 

updated for this feature] 

14. Special Training/Implementation Requirements: 

(list any special 14.1 Release Notes 

training/implementation Issue RL to detail the Contract move process. 

required for this feature. 

Identify what will be required 

to train and implement this 

feature to the customer, i.e., by 

documentation, e-mail, cue 

cards, on sight training, etc.) 
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15. Acceptance Criteria/Test Scenario: 



(list test scenarios required to 
test change prior to user 
acceptance, this can be updated 
after the detailed design is 
completed) REQUIRED 
[Tester should prepare 
checklist based on these test 
scenarios for documentation 
on results of tests. These 
should be matrix from 
identified back to the 
numbering scheme used in 
these test scenarios] 



15.1 Setup test data to ensure that some jobs fail. (See Gail 
Deaton) 

Run a Contract Move process. 

Go to JE-EWO and to the Move Contract icon. 

Verify that a icon exists for Contract Move Results. 

Request report. 

Print repot. 

Verify that the report contains all fields specified. 
Verify that the report data is formatted correctly. 
Verify that the data generated is correct. 
Verify that all data is generated from the Move process. 
Verify that the report contains preconfiguration and 
configuration errors. 

For jobs that fail Move verify that the batch date 
changes. 

Verify that no email messages are sent for errors. 
Correct errors for jobs that failed. 
Rerun batch process. 

Verify that a positive report is generated with no jobs in 
error. 



16. Attachments: 

(copies of screens, reports, etc. 16.1 Report layout 

before and after proposed 

change-only identify if the 

customer requires the screen or 

something on the screen to 

look a certain way.) 
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Signatures of Agreement: 

(add additional rows if necessary) 
BAE: 

Lead Analyst: 



(on file) 6/9/98 
(on file) 6/9/98 
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BAE FUNCTIONAL REQUIREMENT DOCUMENT 



Table # 7182a 



BAE Start Date: 



04/13/1998 



BAE Name: 



Mark Seal 



BAE Comp. Date: 



04/15/1998 



BAE Tele. No.: 



205-977-3618 



BAE Hours: 



4 



LA Assigned: 



CMVC Component Name: 



Scheduling 



Associated Defect/Feature No.: 



identify if this is required 
for an emergency release 
or must be worked in next 
scheduled release] 

Priority: 

(provide priority from 1 04 

'feature priority' list - 
number preliminary 
assigned by SME) 



Target Release: 

(give target release this 
needs to be in) [Only 



2.13 



Target Release Date: 

(give target release date for 
this enhancement, if required) 
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Revision No.: 
Reason for Revision: 



(B, C, etc. - this will require new signatures) 



General: 

(General Information - 
nothing is to be typed here, 
this is for information only 
about the functional spec 
process) 



1 . The purpose of this document is to provide the customer's 
view of the functionality that needs to be changed or added to 
the existing OSPCM product. It is not the detail design 
requirements. It should concentrate on the 'what' that is 
needed and not on the 'how' it is provided. 

2. All features that are > 40 hours/1 business area require a structured 
inspection walk through process (currently using FAGAN). This is 
to be scheduled by the responsible SME for this feature with the 
testing team lead, documentation team lead and the IT development 
Managers. The IT develop managers will assign the appropriate 
representatives to attend the meeting. These inspections are not to 
inspect the author, they are to be used to understand the 
functionality required for development of the 'Detail Design 
Document'. 

3. The 'Analysis Phase Specific' checklist must be used, 
documented and baselined for each feature. 

4. Any correspondence associated with this feature should also 
be documented (i.e., impromptu meetings, phone 
conversations, etc.) and associated with the feature number. 
It should include time, date and participants. 

5. Continue numbering scheme in your text input under each to 
provide traceability for matrixes. 
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1. Abstract: 

(brief description of 
change/addition) - This 
should pretty closely match 
the abstract in CMVC. 

2. Current Problem: 

(brief description of what 
system currently does, what 
needs to be changed, and 
why) 

3. Proposed Solution: 

(brief description of what 
the system will or should do 
and any general constraints 
or conditions that limit the 
solution) 

4. Change/ Addition(s): 

(detailed description of 
change/addition) 



1 . 1 Allow the user to request, view and print the 
scheduling 210 report by wire center, CST/MPT 
number or Res ID. 



2.1 Currently the user must request the entire 
report which can be very large and time 
consuming to view and print. 



3.1 Add a dialog box so the user can specify how 
the report is to be retrieved. 



4. 1 When the user selects the 210 from the print or 
print preview option on the scheduling screen, the 
system will display a dialog box. The user can 
select in this dialog box only one of the following 
options; ALL, RES ID, CST/MPT#, WIRE 
CENTER. 

4.2 When the user selects ALL and clicks OK 
then the entire report is retrieved. 

4.3 When the user selects the RES ID option then 
the system will require that the user enter a valid 
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RES ID for the CMC. Only jobs that have 
activities that are assigned to the RES ID will be 
retrieved and placed on the report. 

4.4 When the user selects CST/MPT# option then 
the system will require that the user enter a valid 
CST/MPT# for the CMC. Only jobs assigned to 
the CST/MPT# entered will be retrieved and 
placed on the report. 

4.5 When the user selects WIRE CENTER option 
then the system will require that the user enter a 
valid WIRE CENTER for the CMC. Only jobs 
assigned to the WIRE CENTER entered will be 
retrieved and placed on the report. 

4.6 In all cases the wire center will be the first sort 
and then the job name will be listed in numerical 
order. 

4.7 Only one option will be allowed when 
selecting "ALL or RES ID or CST/MPT# or wire 
center. 



5. Performance Requirements: 

(list any performance 5.1 Since this is a batch report there may be some processing 

requirements associated time added for this change. 

with this change) [Identify 5.2 On line performance should not be affected by this change, 
system response 
requirements that must be 
met for user acceptance] 



6. Dependencies: 
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(list any defects or features 6.1 NONE 
that this enhancement is 
dependent on or that will be 
dependent on this feature) 
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7. Benefits: 

(provide benefits in dollars, 7.1 This will allow the user to select a report with less 

reduced headcount, time information. Printing the report will save time if there 

savings, etc. for doing this less data on the report. 

work) [This is required to 

identify any savings that can 

be attributed to this feature 

for securing budget approval] 



8. Affected Components: (check) (check) 

Yes No 

RTOC Instructions X 

HELP X 

User Guides X 

Testing X 

Infra-structure X 

Management Reports X 

Database X 
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9. Interfaces 



(list any legacy or new 



9.1 NONE 



interface systems impacted 
by this change) [Make sure 
other interface systems are 
aware of and agree with 
any requirement change 
that impacts them before 
proceeding] 

10. Work-around: (check) (check) 



Yes 



No 



(is there a temporary work 
around?) 

(describe work around in 10.1 Currently the user must 

detail) [Also identify this in request the entire report. 



X 



the OSPCM 'known 



problem' document] 



11. Risks: 



(list factors that impact, 
positive/negative, not doing 
this change) 



11.1 This is a very high user priority. This report will be used 
for scheduling purposes which are already a time 
consuming effort. 
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12. Business Rules: 



If business rules are included 



(list any business rules or 
constraints that should apply. 



12.1 



Valid data for the CMC must be entered when selecting 
RES ID or CST/MPT# or WIRE CENTER. The user 
should be allowed to select only one option at a time. 



in the changes section, 
identify these with asterisk is 
bold, ***business rule***) 



13. Documentation Changes: 

(list affected documents 



13.1 Scheduling user guides and help screens. 



requiring change) 
[Documentation should 
prepare a checklist covering 
each document that must be 
updated for this feature] 

14. Special Training/Implementation Requirements: 

(list any special 14.1 NONE 

training/implementation 

required for this feature. 

Identify what will be required 

to train and implement this 

feature to the customer, i.e., 

by documentation, e-mail, cue 

cards, on sight training, etc.) 
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r 



15. Acceptance Criteria/Test 
(list test scenarios required to 
test change prior to user 
acceptance, this can be 
updated after the detailed 
design is completed) 
REQUIRED [Tester should 
prepare checklist based on 
these test scenarios for 
documentation on results of 
tests. These should be 
matrix from identified back 
to the numbering scheme 
used in these test scenarios] 



Scenario: 

15.1 

• OPEN the scheduling module for a valid CMC. 

• Click on the print button on the tool bar and a list of reports 
is displayed. 

• Select the 2 1 0 scheduling report. 

• A dialog box will open with the following options. 

• ALL 

• RES ID 

• CST/MPT# 

• WIRE CENTER 

• Select ALL and click OK 

• Verify that the entire 210 report is printed. 
15.2 

• OPEN the scheduling module for a valid CMC. 

• Click on the print button on the tool bar and a list of reports 
is displayed. 

• Select the 2 1 0 scheduling report. 

• A dialog box will open with the following options. 

• ALL 

• RES ID 

• CST/MPT# 

• WIRE CENTER 

• Select RES ID and enter a valid RES ID for the CMC and 
click OK. 

• Verify that the 2 1 0 report is printed with only jobs that 
contain the res id entered. 

15.3 

• OPEN the scheduling module for a valid CMC. 
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• Click on the print button on the tool bar and a list of reports 
is displayed. 

• Select the 2 1 0 scheduling report. 

• A dialog box will open with the following options. 

• ALL 

• RES ID 

• CST/MPT# 

• WIRE CENTER 

• Select CST/MPT# and enter a valid CST/MPT# for the 
CMC and click OK. 

• Verify that the 210 report is printed with only jobs that are 
assigned to the CST/MPT# entered. 

15.4 

• OPEN the scheduling module for a valid CMC. 

• Click on the print button on the tool bar and a list of reports 
is displayed. 

• Select the 21 0 scheduling report. 

• A dialog box will open with the following options. 

• ALL 

• RES ID 

• CST/MPT# 

• WIRE CENTER 

• Select WIRE CENTER and enter a valid WIRE CENTER 
for the CMC and click OK. 

• Verify that the 2 1 0 report is printed with only j obs that are 
assigned to the WIRE CENTER entered. 

15.5 

• Verify that only one option can be selected. 

• Verify that the system will not allow entering invalid RES 
ID's, CST/MPT#'s and WIRE CENTERS. 
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15.6 

• OPEN the scheduling module for a valid CMC. 

• Click on the print preview button on the tool bar and a list 
of reports is displayed. 

• Select the 2 1 0 scheduling report. 

• A dialog box will open with the following options. 

• ALL 

• RES ID 

• CST/MPT# 

• WIRE CENTER 

• Select ALL and click OK 

• Verify that the entire 210 report is displayed. 
15.7 

• OPEN the scheduling module for a valid CMC. 

• Click on the print preview button on the tool bar and a list 
of reports is displayed. 

• Select the 2 1 0 scheduling report. 

• A dialog box will open with the following options. 

• ALL 

• RES ID 

• CST/MPT# 

• WIRE CENTER 

• Select RES ID and enter a valid RES ID for the CMC and 
click OK. 

• Verify that the 2 1 0 report is displayed with only jobs that 
contain the res id entered. 

15.8 

• OPEN the scheduling module for a valid CMC. 

• Click on the print preview button on the tool bar and a list 
of reports is displayed. 
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• Select the 2 1 0 scheduling report. 

• A dialog box will open with the following options. 

• ALL 

• RES ID 

• CST/MPT# 

• WIRE CENTER 

• Select CS17MPT# and enter a valid CST/MPT# for the 
CMC and click OK. 

• Verify that the 2 1 0 report is displayed with only jobs that 
are assigned to the CST/MPT# entered. 

15.9 

• OPEN the scheduling module for a valid CMC. 

• Click on the print preview button on the tool bar and a list 
of reports are displayed. 

• Select the 2 1 0 scheduling report. 

• A dialog box will open with the following options. 

• ALL 

• RES ID 

• CST/MPT# 

• WIRE CENTER 

• Select WIRE CENTER and enter a valid WIRE CENTER 
for the CMC and click OK. 

• Verify that the 2 1 0 report is displayed with only jobs that 
are assigned to the WIRE CENTER entered. 

15.10 

• Verify that only one option can be selected. 

• Verify that the system will not allow entering invalid RES 
ID'S, CST/MPT#'s and WIRE CENTERS. 
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16. Attachments: 

(copies of screens, reports, etc. before and after 
proposed change-only identify if the customer 
requires the screen or something on the screen 

Signatures of Agreement: 

(add additional rows if necessary) 
BAE: 

Lead Analyst: 



i 
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BAE FUNCTIONAL REQUIREMENT DOCUMENT 



Table # 701 IB 



BAE Start Date: 



04/17/1998 



BAE Name: 



Gail Deaton 



BAE Comp. Date: 



04/23/1998 



BAE Tele. No.: 



977-3615 



BAE Hours: 



LA Assigned: 



CMVC Component Name: 



jeewo 



Associated Defect/Feature No.: 



identify if this is required 
for an emergency release 
or must be worked in next 
scheduled release] 

Priority: 

(provide priority from Hi 
'feature priority 5 list - 
number preliminary 
assigned by SME) 



Target Release: 

(give target release this 
needs to be in) [Only 



2.14 



Target Release Date: 

(give target release date for 
this enhancement, if required) 



6/1998 
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Revision No.: (B, C, etc. - this will require new signatures) 

Reason for Revision: Walk thru updates and change target release 



General: 

(General Information - 
nothing is to be typed here, 
this is for information only 
about the functional spec 
process) 



1 . The purpose of this document is to provide the customer's 
view of the functionality that needs to be changed or added to 
the existing OSPCM product. It is not the detail design 
requirements. It should concentrate on the 'what' that is 
needed and not on the 'how' it is provided. 

2. All features that are > 40 hours/ 1 business area require a structured 
inspection walk through process (currently using FAGAN). This is 
to be scheduled by the responsible SME for this feature with the 
testing team lead, documentation team lead and the IT development 
Managers. The FT develop managers will assign the appropriate 
representatives to attend the meeting. These inspections are not to 
inspect the author, they are to be used to understand the 
functionality required for development of the 'Detail Design 
Document'. 

3. The 'Analysis Phase Specific' checklist must be used, 
documented and baselined for each feature. 

4. Any correspondence associated with this feature should also 
be documented (i.e., impromptu meetings, phone 
conversations, etc.) and associated with the feature number. 
It should include time, date and participants. 

5. Continue numbering scheme in your text input under each to 
provide traceability for matrixes. 
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1. Abstract: 

(brief description of 
change/addition) - This 
should pretty closely match 
the abstract in CMVC. 



1 . 1 Add "Ex Geoloc" to Splicing and Other 
screens 



2. Current Problem: 

(brief description of what 
system currently does, what 
needs to be changed, and 
why) 



2.1 The "Ex Geoloc" cannot be entered on the 
Splicing and the Other screens. This forces the 
outside craft to type in the "Ex Geoloc" when 
reporting in Work Station. 



3. Proposed Solution: 

(brief description of what 
the system will or should do 
and any general constraints 
or conditions that limit the 
solution) 



3.1 Add the "Ex Geoloc" field to the Splicing and 
Other screens. 



4. Change/ Addition(s): 

(detailed description of 
change/addition) 



4. 1 Add the "Ex Geoloc" field to the Splicing 
and Other screens. The field should be located in 
the substep grid after the "Wire Center" for each 
screen. The format and edits that apply for "Ex 
Geoloc" for the Placing and Removal screen 
should be applied. 

4.2 The Ex Geoloc needs to be populated for 
Splicing and Other substeps (that require the Ex 
Geoloc based on the edits referred to in 4.1) in the 
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MTR extract. This may or may not require a 
change to Work Station. 

5. Performance Requirements: 

(list any performance 5.1 Performance should not be affected. 

requirements associated with 

this change) [Identify system 

response requirements that 

must be met for user 

acceptance] 

6. Dependencies: 

(list any defects or features 
that this enhancement is 
dependent on or that will be 
dependent on this feature) 

7. Benefits: 

(provide benefits in dollars, 7. 1 Accuracy of reporting the Ex Geoloc and a saving in craft 

reduced headcount, time labor by having the Ex Geoloc prepopulated for the 

savings, etc. for doing this substep. 

work) [This is required to 

identify any savings that 

can be attributed to this 

feature for securing budge 

approval] 
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8. Affected Components: 

RTOC Instructions 
HELP 
User Guides 
Testing 

Infra-structure 
Management Reports 
Database 

9. Interfaces 

(list any legacy or new 
interface systems impacted by 
this change) [Make sure 
other interface systems are 
aware of and agree with any 
requirement change that 
impacts them before 
proceeding] 

10. Work-around: 

(is there a temporary work 
around?) 

(describe work around in 
detail) [Also identify this in 
the OSPCM 'known 
problem' document] 



(check) (check) 
Yes No 



X 
X 
X 



X 



X 
X 
X 



9.1 NONE 



(check) 
Yes 
X 



(check) 
No 



10.1 Have the craft continue 
to type in the Ex Geoloc for 
splicing and other work. 
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11. Risks: 

(list factors that impact, 
positive/negative, not doing 
this change) 

12. Business Rules: 

(list any business rules or 12.1 
constraints that should apply. 
If business rules are included 
in the changes section, 
identify these with asterisk is 
bold, ***business rule***) 

13. Documentation Changes: 
(list affected documents 13.1 
requiring change) 
[Documentation should 
prepare a checklist 

covering each document 
that must be updated for 
this feature] 



Ex Geoloc is required for digital loop carrier materials and 
labor. Digital loop carrier materials and labor are 
identified for the substep by the FRC of the substep. 
OSPCM reads the area required indicator for the substep 
FRC in the FRC table. If the indicator is Y then an EX 
Geoloc is required. 

User Guides 
On-line Help 
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14. Special Training/Implementation Requirements: 

(list any special 14.1 NONE 

training/implementation 

required for this feature. 

Identify what will be 

required to train and 

implement this feature to the 

customer, i.e., by 

documentation, e-mail, cue 

cards, on sight training, etc.) 



15. Acceptance Criteria/Test Scenario: 

(list test scenarios required to 15.1 
test change prior to user « 
acceptance. This can be 
updated after the detailed 
design is completed) 
REQUIRED [Tester 
should prepare checklist 
based on these test 
scenarios for 

documentation on results of 
tests. These should be in 
matrix form identified back 
to the numbering scheme ^ 
used in these test scenarios] 



Enter a substep with a 257C "FRC" on the splicing screen. 

• Do not populate the "Ex Geoloc" field and save 
• Error should be returned requiring an entry in the "Ex 
Geoloc" field. 

• Populate the "Ex Geoloc" field with a geoloc of a wire 
center. 

• Verify that a message returns that the entry is 
invalid 

• Populate the "Ex Geoloc" field with a valid entry 

• Verify that the substep can be saved 
Configure, price and firm the job 
Go to workstation 

• Pull up the job and the substep 

• Report 1 hour to the substep and complete 

• Verify that Work Station does not ask user to enter an EX 
Geoloc when reporting on substep. 
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• Verify that the Ex Geoloc is in the MTR extract 

• Repeat above for an "ESTS" work action and 257C FRC on 
the Other screen 

• Enter an "ESTS" work action on the Other screen. Encode 
with an FRC of "45C". Validate that no Ex Geoloc is 
required. 

16. Attachments: 

(copies of screens, reports, 
etc. before and after proposed 
change-only identify if the 
customer requires the screen 
or something on the screen to 
look a certain way) 

Signatures of Agreement: 

(add additional rows if necessary) 
BAE: 

Lead Analyst: 
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BAE FUNCTIONAL REQUIREMENT DOCUMENT 



Table # 6507A 



BAE Start Date: 



June 5 5 1997 



BAE Name: 



Carol A. Brechtel 



BAE Comp. Date: 



June 6, 1997 



BAE Tele. No.: 



205-977-3611 



BAE Hours: 



2.5 Hours 



LA Assigned: 



CMVC Component Name: 



MATMGMT 



Associated Defect/Feature No.: 



6507 



Target Release: 

(give target release this 
needs to be in) [Only 



2.05 



Target Release Date: 

(give target release date for 
this enhancement, if required) 



10/6/97 



identify if this is required 
for an emergency release 
or must be worked in next 
scheduled release] 

Priority: 

(provide priority from production_hi 
'feature priority * list - 
number preliminary 
assigned by SME) 



Exh. 2 - Page 263 



Revision No.: 
Reason for Revision: 



(B, C, etc. - this will require new signatures) 



Subject: 

(brief description of change) 1 . Allow the user to deselect the custom feature "pulling eye". 



Introduction: 

(description of what system 
currently does, what needs 
to be changed, and why) 



1. Custom Feature of outside pulling eye is 
automatically assigned to a substep when: 

* placing fiber cable in the underground 
environment 

* placing copper cable that is assigned a 
Subcategory of PULP or DUCT PIC in the 
Material Item Table 

2. Enhance the system to allow the user to 
deselect the custom feature in the Materials 
Management executable. 



Solution: 

(describe what the system 
will or should do and any 
general constraints or 
conditions that limit the 
solution) 



1. Allow the user to deselect a system generated 
pulling eye custom feature. In Materials the 
change is needed on the Custom Feature window 
when it is displayed from the "Needed 
Requirements for Job XXX" window. 



Change(s): 

(detailed description of 



1 . Materials - from the Needed Requirements for 
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change) - [add additional Job XX window, the user can display the existing 

rows if multiple changes] "Pulling Eye" custom feature or add a new custom 

feature. The user should also be able to deselect 
any existing "Pulling Eye" custom feature passed 
from Job Entry. 



Performance Requirements: 

(list any performance 1 . There should be no noticeable affect on 

requirements associated performance, 
with this change) 



Dependencies: 

(list any defects or features NONE 
that this enhancement is 
dependent on) 



Benefits: 

(provide benefits in dollars, 
reduced headcount, time 
savings, etc. for doing this 
work) 



1 . Allow the user to order fiber cable to be placed in the 
underground environment without a pulling eye. 

2. Allow the user to order copper cable with material 
subcategories of either PULP or DUCT PIC without a pulling 
eyes. 

3. Reduce cost by not ordering custom features that are not 
required. 



Affected Components: 

RTOC Instructions 
HELP 



(check) 
Yes 



(check) 
No 
X 
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User Guides X 
Testing X 

Infra-structure X 
Management Reports X 
Database X 
Interfaces: 

(list any legacy or new NONE 



interface systems impacted by 
this change) 



Work-around: (check) (check) 

Yes No 

(is there a temporary work X 
around?) 

(describe work around in 
detail) 



Risks: 

(list factors that impact, 1 . Cable may be ordered with custom features that are not 
positive/negative, not doing required to do the job, we pay for something we don't need 

this change) and can't use. 



Business Rules: 

(list any business rules or 1 . Allow the user to deselect system generated "Pulling Eye" 

constraints that should apply) custom features. 



Documentation Changes: 

(list affected documents 
requiring change) 



1 . Test Scenario 

2. Functional Decomps 
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Acceptance Criteria/Test Scenario: 



(list test scenarios required to 
test change prior to user 
acceptance. This can be 
updated after the detailed 
design is completed) 
REQUIRED 



1 . Encode a job with at least two substeps 

*one placing fiber cable in the underground environment 
*place copper cable that is in the PULP or DUCT PIC 
material Subcategory (Material Item Table) 

2 . configure and firm the j ob 

3. Exit Job Entry 

4. From the Show a Job's Needed Requirement window, 
display the job 

5. From the Needed Requirements for Job XX window display 
the custom feature window and deselect the pulling eye 
custom feature, both substeps. 

6. Select OK and close the custom feature window 

7. Generate an order for both substeps 

8. Verify that both items do not have custom features 



Attachments: 

(Screen shots are attached)) 1 . Fig. 1 1 is an exemplary screen print for Custom Features 

from the Materials Management executable. 
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Signatures of Agreement: 

(add additional rows if necessary) 
BAE: 

Lead Analyst: 



BAE FUNCTIONAL REQUIREMENT DOCUMENT 



Table # 6844B 



BAE Start Date: 
BAE Comp. Date: 
BAE Hours: 



08/01/1997 
09/10/1997 
42 



BAE Name: 
BAE Tele. No.: 
LA Assigned: 



L. Edgar 
205-977-7375 



CMVC Component Name: 



Change_mgmt 



Associated Defect/Feature No. 



Target Release: 
(give target release this 
needs to be in) [Only 
identify if this is required 
for an emergency release 
or must be worked in next 
scheduled release] 



Target Release Date: 

(give target release date for 
this enhancement, if required) 



Priority: 

(provide priority from 
* feature priority 5 list - 
number preliminary 
assigned by SME) 
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Revision No.: 
Reason for Revision: 



(B, C, etc. - this will require new signatures) 



General: 

(General Information) 1 . All features that are >40 hours/ 1 business area require a 

structured inspection walk through process (currently using 
FAGAN). This is to be scheduled by the responsible SME for 
this feature. 

2. The 'Analysis Phase Specific' checklist must be used, 
documented and baselined for each feature. 

3. Any correspondence associated with this feature should also 
be documented (i.e., impromptu meetings, phone 
conversations, etc.) and associated with the feature number. It 
should include time, date, and participants. 



1. Subject: 

(brief description of change) 1 . Provide methods to route a Complaint to the Contractor 

responsible for problem 
2. Document and track dates, e.g., "Date Sent to Contractor" 
and "Date Returned from Contractor" Fields to be added to 
Complaint presentation. 



2. Introduction: 

(description of what system 1 . Currently there is no OSPCM method to 

currently does, what needs directly send a Complaint to the Contractor 

to be changed, and why) perceived to be at fault, no are specific date fields 

available to enter a date sent to or received from a 
contractor. Also, user cannot directly switch to JE 
or JE-0 to review an associated job which may be 
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related to the Complaint. These capabilities are 
needed to avoid printing and faxing of info and to 
allow quick review of an associated Job. The 
dates are desired by Managers to review 
responsiveness of a contractor to Complaints. The 
data can be used for a Management Report to 
indicate status of Complaints. 



3. Solution: 

(describe what the system 
will or should do and any 
general constraints or 
conditions that limit the 
solution) 



1 . Provide Contractor access by addition of 
Complaints Icon to the Contractor allowed 
applications. Requires security code changes. 

2. Telco District office will enter Complaints 
(may be at a distant location) and needs a revised 
form to first assign to a ResID who later will 
assign to a Contractor. Add fields to the 
Complaint presentation that allows user to select 
the contractor and enter "date sent to contractor'*. 
This could be default to "today" with overwrite 
capability. These fields would need to be added to 
database. These dates could then be used to report 
against in Mgmt. Reports. 

3. Provide new form in Complaints for a 
Contractor to open and review. Then use to 
accept, reject and close the Complaint. Add "date 
for contractor return" for tracking. 

4. Telco may need new form or revised "open 
list " form to review status daily. New field of 
"status" necessary. 
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4. Change(s): 

(detailed description of 
change) - [add additional 
rows if multiple changes] 



1 . Add drop down with valid contractors by CMC 
and the selected nickname will be assigned to 
contractor. 

2. Add date fields entry capability on 
Complaint. 

3. Make ResID field required (Verify closing 
ability) 

4. Add new fields to the database. 

5. Make ResID field a dropdown list for CMC- 
default to logon but allow change. 

6. Add Complaint Icon to Contractor menu with 
associated security addition and WinDDS 
download. 

7. Allow a contractor to close or return a 
Complaint. 



5. Performance Requirements: 

(list any performance 1 . None apparent 

requirements associated 

with this change) [Identify 

system response 

requirements that must be 

met for user acceptance] 



6. Dependencies: 

(list any defects or features 1 . Verify that any IC type of contractor nickname is included in 
that this enhancement is CMC dropdown listing, 

dependent on or that will be 
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dependent on this feature) 



7. Benefits: 

(provide benefits in dollars, 
reduced headcount, time 
savings, etc. for doing this 
work) [this is required to 
identify any savings that 
can be attributed to this 
feature for securing 
budget approval] 



1 . Simplify work process for users. 

2. Better control of contractor administration by assignment to 
responsible contractor. 

3. Manager time saving by avoidance of manual read of 
Complaints or assuming dates sent to or received from 
contractor. 



8. Affected Components: (check) (check) 

Yes No 

RTOC Instructions X 

HELP X 

User Guides X 

Testing X 

Infra-structure X 

Management Reports X 

Database X 



9. Interfaces: 

(list any legacy or new NONE 

interface systems impacted by 

this change) [Make sure 

other interface systems are 

aware of and agree with any 

requirement change that 

impacts them before 

proceeding] 
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10. Work-around 

(is there a temporary work 
around?) 

(describe work around in 
detail) [Also identify this in 
the OSPCM 'known 
problem' document] 



(check) 
Yes 
X 

User may use the existing Mgmt 
Report "Open Complaints" which 
gives the date opened and age of 
Complaint. It has an option to select 
by ResID. 

It would be necessary to then open the 
actual Complaint and look for the 
date sent to contractor in the 
Complaint text. This would have to 
be mandatory by local M&P. 
Send copy of Complaint by Fax to 
contractor. 



(check) 
No 



11. Risks: 

(list factors that impact, 
positive/negative, not doing 
this change) 



1 . User dissatisfaction 

2. Work content not reduced 

3. Contractor responsiveness to customers not easily 
measured 

4. Status of Complaint difficult to determine. 



12. Business Rules: 

(list any business rules or 
constraints that should apply) 



1 . Make ResID a required field. 

2. Allow contractor access only to own data. 

3. M&P to cover local arbitration of disagreements 

4. Contractor responsible for Subcontractor (M&P) 

5. Contractor allowed to close a Complaint 



Exh. 2 -Page 274 



13. Document Changes: 

(list affected documents 1 . Complaint User Guide 

requiring change) 2. Help information 

[Documentation should prepare 
a checklist covering each 
document that must be updated 
for this feature] 
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14. Special Training Requirements: 

(list any special training 1. Update User Guides and Help to reflect 

required for this feature, i.e., 
documentation, e-mail, help, 
cue cards, on sight, etc.) 



15. Acceptance Criteria/Test 

(list test scenarios required to 
test change prior to user 
acceptance. This can be 
updated after the detailed 
design is completed.) 
REQUIRED [Tester 
should prepare checklist 
based on these test 
scenarios for 

documentation on results of 
tests. These should be in 
matrix form identified back 
to the numbering scheme 
use din these test scenarios] 



Scenario: 

1 . Create a Complaint and assign to a ResID. Save and Close. 

2. ResID opens Complaints and searches by ResID for open 
list. 

3. Selects, reviews and determines responsible contractor - 
makes notes in text field. 

4. Assigns to a contractor (by contract # and nickname) in a ' 
dropdown for CMC. 

5. Verify/enter Date Assigned field (default today) 

6. Contractor opens new form "Complaints Assigned" that 
provides search 

7. Contractor selects (receive data populates) Complaint for 
review. 

8. Contractor review (in field or office) and decides to accept 
and fix as written by ResID in test field. 

9. Click field or check boxes to indicate "status" such as accept, 
reject, and close. 

10. Contractor performs work, makes notes in text field, selects 
check box, and enters closed date. Saves. 

11. Telco opens Complaints and "returned list" (new form) 
Search for Complaint and opens to review status and notes 
and closure. 

12. Telco satisfied with status and saves. 

13. Note: Steps #1 thru #12 reflect the normal flow. Other 
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decisions follow and use the normal as a guide. 

14. In step #2, ResID decides that item belongs to another 
Supervisor so either refers back to District office with text 
notes or "reassigns" to correct ResID. 

15. Original Telco/ResID enters correct ID in ResID field, text 
info and saves. 

16. Now return to Step #2 and follow thru to #12 for the 
reassigned ResID. 

17. Next scenario performs Step #1 thru #7 and then in step #8 
contractor does not agree to fix or feels it belongs to another 
(e.g., CATV) 

18. Contractor checks "reject" as in #9 and probably calls 
Telco/ResID to discuss offline. 

19. Verify that steps #1 1 and #12 occur correctly, then assume 
an agreement with text notes (need a form of date tracking 
for such cases) 

20. Return to step #8 for acceptance and on thru #12 

21 . Next case uses step #1 thru #7 and then #18 thru #20 and 
now Telco/ResID agrees that item needs to go to different 
contractor (e.g., BSW versus MM) or could be non Telco 
work (CATVO and need to notify complainer. 

22. Enter new "assignment", make text notes and Save. 

23. Possible that #21 will also require closing of time-enter date 
and save. 

24. Dates and status should be verified in the dB. 

25. When available, Management Report should be verified. 

26. Next scenario adds a related job as in existing Complaints 
module. 

27. Perform steps #1 thru #12 but at step #3 see the Complaints 
User Guide and relate a Job to the item. Verify that related 
info follows thru process. 
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28. Review info as needed then Cancel or Exit to return to 
Guide. 



16. Implementation: 

(Identify if there is any 
special implementation 
issues that need to be 
addressed, i.e., field 
deployment; etc.) 



1 . Local agreements is needed as to arbitration methods for 
returned/rejected Complaints 

2. Train District Complaint taker, ResIDs and contractor in new 
methods 



17. Attachments: 

(copies of screens, reports, 1 . 
etc. before and after proposed 2. 
change) 3. 

4. 

5. 



Screens for the following are shown in Figs. 12-16. 
First Open (Note: Will print attached, Placeholders On) 
Open by ResID 
Search results 
Contractor complete 
Close by ResID 



Signatures of Agreement: 

(add additional rows if necessary) 

BAE: L.Edgar 

Lead Analyst: M. Eike 

Fig. 12 is an exemplary screen print for opening a New Complaint in OSPCM. 

Fig. 13 is an exemplary screen print for Open Complaint, which the Supervisor [ResID] can log on 

and open Complaints. 

-displays above search form 

-situation is daily view so would used ResID? Can this populate based on logon? 
-could we adapt to also use for contractor with some fields inactive? 
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Fig. 14 is an exemplary screen print for Search Results. 

After ResID opens Complaint and does search based on address 

Decides to relate BSW job to Complaint-may be wrong- visit will help 

Fig. 15 is an exemplary screen print for Complaint on a Job. Fig. 16 is an exemplary flow chart 
from creating a complaint to satisfying the complaint 
Notes for Fig. 16: 

(1) toggle may be an Icon or other method to allow ResID to switch to JE or JE-0 for job review 
& return. 

(2) OP AC is used as creator but may be a District Office or other. 

(3) Auto Date refers to a default or auto populated date. 

(4) Dialog implies tel conversations or such to locally resolve rejection-text will help. 
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BAE FUNCTIONAL REQUIREMENT DOCUMENT 



03/04/1998 
03/25/1998 



BAE Start Date: 
BAE Comp. Date: 
BAE Hours: 4 

CMVC Component Name: je ewo 



Table # 7000C 



BAE Name: Gail Deaton 

BAE Tele. No.:(205) 977-3615 
LA Assigned: 



Associated Defect/Feature No.: 



Target Release: 
(give target release this needs 
to be in) [Only identify if this 
is required for an emergency 
release or must be worked in 
next scheduled release] 



2.12 



Target Release Date: 

(give target release 
date for this 
enhancement, if 
required) 



06/98 



Priority: 

(provide priority from 'feature 
priority' list -number 
preliminary assigned by SME) 



hi 



Revision No.: 
Reason for Revision: 



C (B, C, etc. - this will require new signatures) 

Add comments and corrections identified in walkthru on 3/24 



General: 

(General Information - nothing 1 . 
is to be typed here, this is for 
information only about the 
functional spec process.) 



The purpose of this document is to provide the customer's view 
of the functionality that needs to be changed or added to the existing 
OSPCM product. It is not the detail design requirements. It should 
concentrate of 'what' is needed and not on the 'how' it is provided. 
2. All features that are >40 hours/1 business area require a 
structured inspection walk through process (currently using FAGAN). 
This is to be scheduled by the responsible SME for this feature with the 
testing team lead, documentation team lead and the IT development 
Managers. The IT development Managers will assign the appropriate 
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representatives to attend the meeting. These inspections are not to 
inspect the author, they are to be used to understand the functionality 
required for development of the 'Detail Design Document 5 . 

3. The 'Analysis Phase Specific' checklist must be used, 
documented and baselined for each feature. 

4. Any correspondence associated with this feature should also be 
documented (i.e., impromptu meetings, phone conversations, etc.) and 
associated with the feature number. It should include time, date, and 
participants. 

5. Continue numbering scheme in your text input under each table 
to provide traceability for matrixes. 



1. Abstract: 

(brief description of 1.1 Order quantity for stub should always be "1". Do not allow 

change/addition user to change. 

- This should pretty closely 
match the abstract in CMVC. 



2. Current Problem 

(brief description of what 
system currently does, what 
needs to be changed and why) 



2.1 Field users are entering the footage of the stub. These stubs 
come already in pre-determined footages as described in the material 
description. When the user enters the footage of the stub in the order 
quantity, then that quantity of stubs are ordered. 



3. Proposed Solution: 

(brief description of what the 3.1 The field is prepopulated with the order quantity for stubs to 

system will or should do an "1". Do not allow any changes to the prepopulated data. 

any general constraints or 

conditions that limit the 

solution) 
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4. Change/Addition(s): 

(detailed description of 4.1 On the Placing screen in je_ewo, the order quantity for stub is 

change/addition) defaulted to "1". 

Do not allow the user to change the prepopulated "1" in the order 
quantity field for the material category of CABLE-STUB and the 
material subcatagory of STUB. 

5. Performance Requirements: 

(list any performance 5 . 1 Performance should not be affected, 

requirements associated with 
this change) 

[Identify system response 
requirements that must be 
met for user acceptance] 

6. Dependencies: 

(list any defects or features that 6. 1 
this enhancement is dependent 
on or that will be dependent on 
this feature) 

7. Benefits: 

(provide benefits in dollars, 
reduced headcount, time 
savings, etc. for doing this 
work) [This is required to 
identify any savings that can 
be attributed this feature for 
securing budget approval] 

8. Affected Components: (Check) (Check) 

Yes No 



7. 1 Save the field users from ordering and receiving large quantities 
of cable stubs from the factory and then having to process the returns. 



Exh. 2 -Page 282 



RTOC Instructions 

HELP 

User Guides 

Testing 

Infra-structure 

Management Reports 

Database 

9. Interfaces: 

(list any legacy or new 
interface systems impacted by 
this change) [Make sure other 
interface systems are aware 
of and agree with any 
requirement change that 
impacts them before 
proceeding] 

10. Work-around: 

(is there a temporary work 
around?) 

(describe work around in 
detail) 

[Also identify this in the 
OSPCM 'known problem' 
document] 

11. Risks: 

(list factors that impact, 
positive/negative, not doing 
this change) 



x 



x 



9.1 



(Check) 
Yes 



10.1 



(Check) 
No 

X 



11.1 Continue to allow field users to order and pay for huge 
quantities of cable stubs. 
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12. Business Rules: 

(list any business rules or 12.1 Job Entry EWO on the Placing screen. . .Any substep entered 

constraints that should apply. with the material category of CABLE-STUB and the subcategory of 
If business rules are included STUB should always default to "1" in the Order Quantity field. The 
in the changes section, identify user should not be able to change this default, 
these with asterisk in bold, 
***business rule***) 



13. Documentation Changes: 
(list affected documents 
requiring change) 
[Documentation should 
prepare a checklist covering 
each document that must be 
updated for this feature] 



13.1 Change On-Line Help to indicate that the Order Quantity field 
for the material category of CABLE-STUB and the subcategory of 
STUB cannot be changed by the user. 



14. Special Training/Implementation Requirements: 

(list any special 14.1 Send out OSPCM Product Bulletin 

training/implementation 

required for this feature. 

Identify what will be required 

to train and implement this 

feature to the customer, i.e., by 

documentation, e-mail, help, 

cue cards, on sight training, 

etc.) 



15. Acceptance Criteria/Test Scenario: 

(list test scenarios required to 15.1 Enter a cable stub in the "A" environment. Verify that the 
test change prior to user Order Quantity field is prepopulated with a "1". Save the substep, 

acceptance, this can be updated configure and price. Firm the price. Go to materials management and 
after the detailed design is verify that the cable stub is in the "N" status on the requirements screen, 

complemented.) REQUIRED Repeat the above for "B" "U" "H" environments. 
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[Tester should prepare 
checklist based on these test 
scenarios for documentation 
on results of tests. These 
should be in matrix from 
identified back to the 
numbering scheme use in 
these test scenarios] 



Enter a stub substep and try to blank out the prepopulated quantity of 
"1". The system should not allow this. 

Enter a stub substep and try to overtype the prepopulated quantity of 
"1" with a "0". The system should not allow this. 



17. Attachments: 

(copies of screens, reports, etc . 16.1 
before and after proposed 
change - only identify if the 
customer requires the screen or 
something on the screen to 
look a certain way) 



Signatures of Agreement: 

(add additional rows if necessary) 
BAE: 

Lead Analyst: 



BAE FUNCTIONAL DOCUMENT 

Table # 7002B 

BAE Start Date: 09/09/1997 BAE Name: Gail Deaton 

BAE Comp. Date: 05/21/1998 BAE Tele. No.:977-3615 

BAE Hours: 20 LA Assigned: 

CMVC Component Name: je ewo 

Associated Defect/Feature No.: 



Target Release 

(give target release this 
needs to be in) [only 
identify if this is 



Target 

2.15 



Release Date: 

(give target release date 
for this enhancement, if 
required 
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required for an 
emergency release or 
must be worked in 
next scheduled release] 

Priority: 

(provide priority from 'feature Production_hi 
priority' list -number 
preliminary assigned by SME) 

Revision No.: B (B, C, etc. - this will require new signatures) 

Reason for Revision: 

General: 

(General information - nothing 1 . The purpose of this document is to provide the customer's view 
to be typed here, this is for of the functionality that needs to be changed or added to the existing 
information only about the OSPCM product. It is not the detail design requirements. It should 

functional spec process) concentrate of 'what' is needed and not on the 'how' it is provided. 

2. All features that are >40 hours/ 1 business area require a 
structured inspection walk through process (currently using FAGAN). 
This is to be scheduled by the responsible SME for this feature with the 
testing team lead, documentation team lead and the IT development 
Managers. The IT development Managers will assign the appropriate 
representatives to attend the meeting. These inspections are not to 
inspect the author, they are to be used to understand the functionality 
required for development of the 'Detail Design Document'. 

3. The 'Analysis Phase Specific' checklist must be used, 
documented and baselined for each feature. 

4. Any correspondence associated with this feature should also be 
documented (i.e., impromptu meetings, phone conversations, etc.) and 
associated with the feature number. It should include time, date, and 
participants. 

5. Continue numbering scheme in your text input under each table 
to provide traceability for matrixes. 
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1. Abstract: 

(brief description of 

change/addition 

- This should pretty closely 

match the abstract in CMVC. 



Reopen or close jobs 

Create a new process and screen for EWO and PWO type 
jobs that will allow the user to reopen a job after auto close. 
Create a new process and screens for EWO and PWO type 
jobs that will allow the user to close a job manually before 
the auto close process. 



2. Current Problem: 

(brief description of what 
systems currently does, what 
needs to be changed, and why) 



Reopen or close jobs 

Create there is not a process that will allow the user to reopen a 
EWO or PWO after that job has been auto closed. A new process and 
new screens need to be created to allow the user to reopen a closed 
EWO or PWO. 



Currently there is not a process that will allow the user to 
close a EWO or PWO before the auto close process. 
A new process and new screens need to be created to allow the 
user to close a EWO or PWO before the auto close process. 



3. Proposed Solution: 

(brief description of what the 
system will or should do an 
any general constraints or 
conditions that limit the 
solution) 



Reopen or close jobs 

Create new REOPEN JOB menu, toolbar and screens that 
will allow the user to reopen a closed job. 

Create new CLOSE JOB menu, toolbar and screens that will 
allow the user to close a job. 



Need to capture the previous and last CUIDs (or last 2 
instances) of who reopened and closed jobs. 



4. Change/ Addition(s): 

(detailed description of 



4. Reopen or close jobs 
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change/addition) 4. 1 Create a new icon (REOPEN JOB) and place on 

the je_ewo tool bar. Icon should always to active. 
This icon should allow the user to access a new screen to 
reopen a closed EWO or PWO. 

4.1.1 The new screen labeled REOPEN JOB 
should contain: 

4.1.1.1 State 

4.1.1.2 CMC 

4.1.1.3 Job Name field 

4. 1 . 1 .4 There should also be a grid labeled 
Job Name which will contain a drop 
down of closed jobs when search is 
selected. 

4.1.1.5 The user will enter or select the job 
name desired. 

4.1.1.6 EMU should be generated if the job 
number entered is not a closed job. 

4. 1 . 1 .7 EMU should be generated if job is 
invalid for state. 

4.1.2 Once entered OSPCM should display a 
new screen with the following 

prepopulated information: 

4.1.2.1 Job Name 

4.1.2.2 State 

4.1.2.3 CMC 

4.1.2.4 The "end-date" of the job 

4. 1 .2.5 The "closed" date of the job. 

4. 1 .2.6 The user should be given two options 
to reopen the job: 

4. 1 .2.6. 1 Reopen the job and reset 
end date to today's date. 
This option will start the 
auto close counter and 
close the job based on the 
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auto close default in the 
OPF table for this CMC. 
4. 1 .2.6.2 Reopen the job and leave 
open. This option will 
leave the job open until it 
is manually closed by the 
user. To do this set the 
Progressive Job Indicator 
to T. 

4.2 Close job 

4.2. 1 Create a new icon (CLOSE JOB) and place on 
the main jeewo tool bar. Icon should always 
be active. This icon should allow the user to 
access a new screen to Close a EWO or PWO. 

4.2.2 Create a new screen and label CLOSE JOB. 
Screen should contain: 

4.2.2.1 State 

4.2.2.2 CMC 

4.2.2.3 Job Name 

4.2.2.4 Job Name grid. This grid should 
contain a drop down of all open job 
when Search is selected. 

4.2.2.5 The user will enter or select the job 
number desired. 

4.2.2.6 EMU should be issued if the job 
number entered is already closed. 

4.2.2.7 EMU should be generated if job is 
invalid in State. 

4.2.3 Once entered OSPCM should query and 
display the following job information on a 
new screen. 

4.2.3.1. If there are substeps open on 
the job, List the Work ID, 
Print, Step, WE and WA for 
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all substeps and the Material 
Description (for placing and 
removal screen) of the open 
substeps. Issue message to 
user that the above substeps 
are open and the job cannot 
be closed. 

4.2.4 If all the substeps are closed. Create a new 
screen labeled CLOSE JOB. The screen 
should contain: 

4.2.4.1.1 Job Name 

4.2.4.1.2 State 

4.2.4.1.3 CMC 

4.2.4. 1 .4 All the substeps for this job are 
complete. The last substep close 
date is xx/xx/xxxx. Please enter 
the job close date. Field should be 
labeled Close Date. 

4 .2 .4 . 1 . 5 Job close date must be between 
and can include last substep close 
date and current date. 

4.2.4. 1 .6 EMU should be generated if 
outside of range. 



5. Performance Requirements: 

(list any performance 5 Standard three second response time should be adhered, 

requirements associated with 
this change) 

[Identify system response 
requirements that must be 
met for user acceptance] 
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6. Dependencies: 

(list any defects or features that 
this enhancement is dependent 
on or that will be dependent on 
this feature) 

7. Benefits: 

(provide benefits in dollars, 
reduced headcount, time 
savings, etc. for doing this 
work) [This is required to 
identify any savings that can 
be attributed this feature for 
securing budget approval] 

8. Affected Components: 

RTOC Instructions 
HELP 

User Guides 
Testing 
Infra-structure 
Management Reports 
Database 

9. Interfaces: 

(list any legacy or new 
interface systems impacted by 
this change) [Make sure other 
interface systems are aware 
of and agree with any 
requirement change that 
impacts them before 



6 None 



7 Currently the user calls the HELP desk for OSPCM to reopen 
or close a job. This process is timely for the user and it also adds 
volume to the HELP desk troubles. This feature will allow the user to 
perform these functions in a quick manner. 



(Check) 
Yes 



x 
x 

X 
X 



(Check) 
No 



9 None 
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proceeding] 



10. Work-around: 

(is there a temporary work 
around?) 

(describe work around in 
detail) 

[Also identify this in the 
OSPCM 'known problem' 
document] 

11. Risks: 

(list factors that impact, 1 1 None 

positive/negative, not doing 
this change) 

12. Business Rules: 

(list any business rules or 1 2 Any user with je_ewo access can reopen or close jobs. 

constraints that should apply. 

If business rules are included 

in the changes section, identify 

these with asterisk in bold, 

***business rule***) 

13. Documentation Changes: 

(list affected documents 1 3 Job Entry_EWO guide, 

requiring change) On-line Help 

[Documentation should 
prepare a checklist covering 
each document that must be 
updated for this feature] 



(Check) (Check) 
Yes No 

X 

10 Continue to use the HELP desk. 



Exh. 2 - Page 292 



14. Special Training/Implementation Requirements: 

(list any special 14 Release Notes 

training/implementation 

required for this feature. 

Identify what will be required 

to train and implement this 

feature to the customer, i.e., by 

documentation, e-mail, help, 

cue cards, on sight training, 

etc.) 

15. Acceptance Criteria/Test Scenario: 

(list test scenarios required to 15 See Attachment 

test change prior to user 

acceptance, this can be updated 

after the detailed design is 

complemented.) REQUIRED 

[Tester should prepare 

checklist based on these test 

scenarios for documentation 

on results of tests. These 

should be in matrix from 

identified back to the 

numbering scheme use in 

these test scenarios] 



16. Attachments: 

(copies of screens, reports, etc. 
before and after proposed 
change - only identify if the 
customer requires the screen or 
something on the screen to 
look a certain way) 



Attachments of proposed screens 
Test scenarios 
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Signatures of Agreement: 

(add additional rows if necessary) 
BAE: (on file) 5/28/98 

Lead Analyst: (on file) 5/28/98 
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BAE FUNCTIONAL DOCUMENT 

Table # 2375 

BAE Start Date: June 15, 1997 BAE Name: Carol A. Brechtel 

BAE Comp. Date: June 16, 1997 BAE Tele. No.:205-977-3611 

BAE Hours: 1 LA Assigned: 

CMVC Component Name: MATMGMT 
Associated Defect/Feature No.: 6574 



Target Release 

(give target release this 2. 1 
needs to be in) 



Target Release Date: 

(give target release date 
for this enhancement, if 
required 



Priority: 

(provide priority from 'feature Production_hi 
priority' list - production_hi 
through deferredlow) 

Revision No.: 
Reason for Revision: 



Subject: 

(brief description of change) 1 Allow the user to scan for inventory items with less quantity 

than required. 



Introduction: 

(description of what system 1 The automatic inventory scan only searches for an displays 
currently does, what needs to existing inventory equal to or greater than the smallest requirement, 
be changed, and why) Need to enhance the system to find and display ALL like existing 

inventory. 



Solution: 

(describe what the system will 1 Small inventory scan (automatic scan) should display ALL 
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or should do and any general 
constraints or conditions that 
limit the solution) 



existing inventory found to satisfy the requirement regardless of the 
quantity needed to satisfy the requirements. 



Changes: 

(detailed description of 
change) [add additional rows 
of multiple changes] 



1 Automatic inventory scan should display ALL existing 

inventory for like materials. Allow the user to view cable items that a 
less than the quantity needed on the requirement. 



Performance Requirements: 

list any performance 
requirements associated with 
this change) 



There should be no noticeable affect on performance. 



Dependencies: 

(list any defects or features that 1 
this enhancement is dependent 
on) 



None 



Benefits: 

(provide benefits in dollars, 
reduced headcount, time 
savings, etc. for doing this 
work) 



1 Allow the user to see all existing inventory for the material 
description requested on the scan 

2 Use existing inventory to satisfy a job's requirements 



Affected Components: 



(Check) 
Yes 



(Check) 
No 
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RTOC Instructions 
HELP 

User Guides 
Testing 
Infra-structure 
Management Reports 
Database 



Interfaces: 

(list any legacy or new 1 None 

interface systems impacted by 
this change) 



(Check) (Check) 
Work-around: Yes No 

(is there a temporary work x 
around?) 

(describe work around in 1 . 

detail) 



Risks: 

(list factors that impact, 1 . Material may be ordered when existing inventory could be 

positive/negative, not doing used, 
this change) 

Business Rules: 

(list any business rules or 
constraints that should apply) 

Documentation Changes: 

(list affected documents 
requiring change) 
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1 . Display all existing inventory that satisfies the requested scan, 
regardless of the quantity. 



1 . Material Management User Guide 

2. Functional Decomps 

3. Test Scenarios 



Acceptance Criteria/Test Scenario: 

(list test scenarios required to 1 
test change prior to user 2 
acceptance) REQUIRED 

3 
4 
5 
6 



Encode or select a job with cable requirements 

Build unassign or surplus inventory to satisfy the requirements. 

Build the material into several inventory sites. 

Display the "Job Needed Requirements for Job XX" window 

Select the substep for the cable requirement 

Execute an inventory scan 

Verify that the scan returns ALL like inventory, regardless of the 
quantity 

Assign and/or transfer the material. Depending on where the 
material is located will determine if you need to assign or request 
transfer. (Test Scenario may need to be updated if Feature #6574 
worked before this feature) 



Attachments: 

(copies of screens, reports, etc. 1 . None 

before and after proposed 

change) 

Signatures of Agreement: 

(add additional rows if necessary) 
BAE: 

Lead Analyst: 
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BAE FUNCTIONAL DOCUMENT 

Table #7012A 

BAE Start Date: May 8, 1998 BAE Name: Carol A. Brechtel 

BAE Comp. Date: May 11, 1998 BAE Tele. No.:205-977-3611 

BAE Hours: 3 hours LA Assigned: Karin Olinger 

CMVC Component Name: MATMGMT 
Associated Defect/Feature No.: 



Target Release 
(give target release this 
needs to be in) [only 
identify if this is 
required for an 
emergency release or 
must be worked in 
next scheduled release] 



Target Release Date: 

(give target release date 
for this enhancement, if 
required 



Priority: 

(provide priority from 'feature 
priority' list - number 
preliminary assigned by SME) 



Revision No.: 
Reason for Revision: 



(B, C, etc. - this will require new signatures) 



General: 

(General Information - nothing 1 . 
is to be typed here, this is for 
information only about the 
functional spec process.) 



The purpose of this document is to provide the customer's view 

of the functionality that needs to be changed or added to the existing 

OSPCM product. It is not the detail design requirements. It should 

concentrate of 'what' is needed and not on the 'how' it is provided. 

2. All features that are >40 hours/ 1 business area require a 

structured inspection walk through process (currently using FAG AN). 

» 

This is to be scheduled by the responsible SME for this feature with the 
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testing team lead, documentation team lead and the IT development 
Managers. The IT development Managers will assign the appropriate 
representatives to attend the meeting. Th4ese inspections are not to 
inspect the author, they are to be used to understand the functionality 
required for development of the 'Detail Design Document'. 

3. The 'Analysis Phase Specific' checklist must be used, 
documented and baselined for each feature. 

4. Any correspondence associated with this feature should also be 
documented (i.e., impromptu meetings, phone conversations, etc.) and 
associated with the feature number. It should include time, date, and 
participants. 

5. Continue numbering scheme in your text input under each table 
to provide traceability for matrixes. 



1. Abstract: 

(brief description of 1.1 Enhance Materials to read the Job Entry substep remarks and 

change/addition populate the order item remarks when the order is created. 

- This should pretty closely 
match the abstract in CMVC. 



2. Current Problem: 

(description of what system 2.1 Today the order remark and order line item remarks can not be 
currently does, what needs to populated until the order is created in the Materials Management 
be changed, and why) executable. Any substep remarks entered while encoding the jobs are 

not read by materials. This feature will allow the user to encode 
substep remarks while encoding the job and materials will pre-populate 
the order line items remarks with the substep remarks when the order is 
created. 



3. Proposed Solution: 

(describe what the system will 3 . 1 Any substeps remark entered during encoding will be read by 

or should do and any general materials and the substep remark will appear as the order line item 

constraints or conditions that remark when the order is created. 

limit the solution) 3.2 A substep remark can be up to 250 characters but an order item 
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33 

4. Changes/ Addition(s): 

(detailed description of 4.1 
change) 

4.2 

4.3 
4.4 

4.5 
4.6 

5. Performance Requirements: 

(list any performance 5 . 1 

requirements associated with 
this change) [Identify system 
response requirements that 
must be met for user 
acceptance] 



remarks can only be 35 characters, so a substep remark longer 
than 35 characters will be truncated. 

The order line remark will be populated with the first 35 characters 
of the first remark of the first substep that makes up that order 
item. 

When a order is created, materials will read the substep remarks 
and populate the order item remarks with the information. The 
remarks will be sent to OrderMaster. 

Substep remark can be up to 250 characters (longer if multiple 
remarks) but only 35 characters can be sent to OrderMaster. So a 
substep remark longer than 35 characters will be truncated. The 
system will populate the order item remarks with the first 35 
characters of the substep remark. 

The user will need the ability to edit the order item remarks before 
sending the order to OrderMaster (available today). 
The system will populate the order item remarks with the first 35 
characters of the first remark of the first substep aggregated to the 
order item. 

Materials will read all substep remarks when an order is created no 
just the substep remarks associated with DLC/COE equipment. 
If the order is marked as emergency and one of the substeps is for 
consignment material, the substep remark will be overwritten with 
the ship from consignment remark. This is currently being done by 
the system. 

There should be no noticeable affect on performance 
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6, Dependencies: 

(list any defects or features that 6. 1 
this enhancement is dependent 
on or that will be dependent on 
this feature) 



None 



7. Benefits: 

(provide benefits in dollars, 
reduced headcount, time 
savings, etc. for doing this 
work) [This is required to 
identify any saving that can 
be attributed this feature for 
securing budget approval] 



7. 1 The user will have the ability to encode any order item remarks 
while encoding the job(as substep remarks). 

7.2 In many of the districts material is being ordered by the 
Construction Supervisor they do not remember or know what 
remarks needs to be sent tot he vendor when ordering Central 
Office Equipment. 



8. Affected Components: 



(Check) 
Yes 



(Check) 
No 



RTOC Instructions 
HELP 

User Guides 
Testing 
Infra-structure 
Management Reports 
Database 



x 
x 
x 



X 
X 
X 



9. Interfaces: 

(list any legacy or new 9. 1 

interface systems impacted by 
this change) [Make sure other 
interface systems are aware 
of and agree with any 
requirement change that 



None 
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impacts them before 
proceeding] 



10. Work-around: 

(is there a temporary work 
around?) 

(describe work around in 
detail) 

[Also identify this in the 
OSPCM 'known problem' 
document] 

11. Risks: 

(list factors that impact, 
positive/negative, not doing 
this change) 

12. Business Rules: 

(list any business rules or 
constraints that should apply. 
If the business rules are 
included in the changes 
section, identify these with 
asterisk in bold, ***business 
rule***) 

13. Documentation Changes: 
(list affected documents 
requiring change) 
[Documentation should 
prepare a checklist covering 



(Check) (Check) 
Yes No 

x 

10.1 The user must remember to enter the order item remarks on the 
Generate Order window before the order is sent to OrderMaster. 



11.1 Today material is being ordered without the correct remarks 
being sent tot he vendor. 

11.2 Material can be ordered and the user not get exactly what they 
required or the material may be shipped to the incorrect location. 



12.1 If the order is marked as emergency and for consignment material 
any substeps remarks will be over written with the ship from 
consignment remark. 

1 2.2 For this to work properly the user must populate the substep 
remark field. 

12.3 The system will populate the order item remarks with the first 35 
characters of the first remark of the first substep aggregated to 
that order item. 



13.1 Job Entry User Guide (to inform the user where the remarks 
should be entered and that only the first 35 characters are sent to 
OrderMaseter). 

13.2 Functional Decomps 
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each document that must be 13.3 Help, for both Job Entry & Materials Management 

updated for this feature] 1 3 .4 Test Scenario 

13.5 Material Management User Guide 

13.6 Material Management Business Solution(s) 



14. Special Training/Implementation Requirements: 

(list any special 14.1 None 

training/implementation 

required for this feature. 

Identify what will be required 

to train and implement this 

feature to the customer, i.e. by 

documentation, e-mail, help, 

cue cards, on-sight training, 

etc.) 



Acceptance Criteria/Test Scenario: 
(list test scenarios required to 15.1 
test change prior to user 
acceptance, this can be updated 
after the detailed design is 
completed.) REQUIRED 
[Tester should prepare 
checklist based on these test 
scenarios for documentation 
on results of tests. These 15.2 
should be in matrix from 15.3 
identified back to the 
numbering scheme used in 
these test scenarios] 1 5 .4 



15.5 



Encode a job with multiple substeps: one for DLC equipment 
with a substep remark of 35 characters or less, one for DLC 
equipment with a substep remark with more than 35 characters, 
encode several substeps for cable that will be aggregated when 
the order is created and put a substep remarks on all cable 
substeps, encode one substep for consignment material, encode a 
substep with multiple remarks, and encode several substep 
without substep remarks. 
Configure, price and firm the job 

In Materials Management create an order and verify that the 
substep remarks have been populate in the order item remarks 
field. 

For the consignments item verify that when the order is sent to 
OrderMaster that the order item remarks was changed tot he shop 
from consignment remarks. 

For the aggregate cable order verify that the order item remarks is 
populated with the substep remark from the first aggregate item. 



Exh. 2 - Page 304 



15.6 



For the item that was encoded with a substep remark greater than 
35 characters verify that the remark was truncated and the order 
item remarks was populated with the first 35 characters. 



15.7 



Verify that all remarks are being passed to OrderMaster properly. 
I have listed all the items that need to be test, this can be done by 
encoding one job or multiple jobs, but created one order or 



multiple orders I will leave this up to the tester. 



16. Attachments: 

(copies of screens, reports, etc. 16.1 None 

before and after proposed 

change - only identify if the 

customer requires the screen or 

something on the screen to 

look a certain way) 

Signatures of Agreement: 

(add additional rows if necessary) 



Lead Analyst: 



BAE: 



(on file) 5/14/98 
(on file) 5/14/98 
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BAE FUNCTIONAL DOCUMENT 



BAE Start Date: 
BAE Comp. Date: 
BAE Hours: 



05/22/1998 
06/04/1998 
10 



CMVC Component Name: 
Associated Defect/Feature No.: 



Table # 7017B 



BAE Name: Gail Deaton 

BAE Tele. No.:2 05-977-3615 
LA Assigned: 



je_ewo 



Target Release 
(give target release this 
needs to be in) [only 
identify if this is 
required for an 
emergency release or 
must be worked in 
next scheduled release] 



2.15 



Target Release Date: 

(give target release date 
for this enhancement, if 
required 



Priority: 

(provide priority from 'feature 
priority' list - number 
preliminary assigned by SME) 



Production hi 



Revision No.: 
Reason for Revision: 



B (B, C, etc. - this will require new signatures) 

Walkthru changes 



General: 

(General information - nothing 1 . The purpose of this document is to provide the customer's view 
to be typed here, this is for of the functionality that needs to be changed or added to the existing 

OSPCM product. It is not the detail design requirements. It should 
concentrate of 'what' is needed and not on the 'how' it is provided. 
2. All features that are >40 hours/ 1 business area require a 
structured inspection walk through process (currently using FAGAN). 
This is to be scheduled by the responsible SME for this feature with the 



information only about the 
functional spec process) 
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1. Abstract: 

(brief description of 

change/addition 

- This should pretty closely 

match the abstract in CMVC. 

2. Current Problem 

(brief description of what the 
system will or should do and 
any general constraints or 
conditions that limit the 
solution) 



3. Proposed Solution: 

(brief description of what the 
system will or should do an 
any general constraints or 



\ 



testing team lead, documentation team lead and the IT development 
Managers. The IT development Managers will assign the appropriate 
representatives to attend the meeting. Th4ese inspections are not to 
inspect the author, they are to be used to understand the functionality 
required for development of the 'Detail Design Document'. 

3. The 'Analysis Phase Specific' checklist must be used, 
documented and baselined for each feature. 

4. Any correspondence associated with this feature should also be 
documented (i.e., impromptu meetings, phone conversations, etc.) and 
associated with the feature number. It should include time, date, and 
participants. 

5. Continue numbering scheme in your text input under each table 
to provide traceability for matrixes. 

1 Placing screen and Placing Replaced Item screen - CWI 
Information grid - Enable to CWI Qty field for all substeps. 



2. The CWI Information grid is only enabled for substeps that 
require a Depth, Width, Diameter, New/Existing. Substeps not 
requiring the entries read the Record Qty as the CWI Qty. It has been 
identified that work actions such as PLAC2 can have a CWI Qty 
different that they Record Qty. Precast manholes in the 1995 Regional 
Contract are calculated on cubic feet. The user needs to be able to enter 
the cubic feet in the CWI Qty field. This feature will allow the user to 
enter the actual CWI Qty for contract work. 

3 . Enable CWI Qty on the Job Entry Placing and the Placing 
Replaced Item Screen for all substeps. 
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conditions that limit the 
solution) 

4. Change/ Addition (s): 
(detailed description of 4. 
change/addition) 



Job Entry - Placing screen Enable the CWI Qty field in the 
CWI Information grid for all substeps entered on the Placing 
screen and the Placing Replaced Item screen 

4. 1 The Depth, Width, Diameter, New/Existing fields 

should continue to be enabled and defaulted as 
currently coded. The CWI Qty is presently required 
when the CWI Qty is presently required when the 
CWI Information fields of Depth, Width, Diameter or 
New/Existing is prepopulated. 

4.2 For substeps not using Depth, Width, Diameter, 
New/Existing 

4.2.1 CWI Qty is enabled but input it is optional. 

4.2.2 "0" zero is not allowed 

4.2.3 Null or blank is allowed 
4.3 Preconfiguration of substep 

4.3.1 Determine if the substep is "C" contract or 
T telco 

4.3.1.1 If the substep is "T" telco 

4.3.1.1.1 Always use the Record 
Qty for STIs 

4.3.1.1.2 CWI Qty is ignored 

4.3.1.2 If the substep is "C" contract 

4.3 . 1 .2. 1 Always use the Record 
Qty for STIs 

4.3. 1 .2.2 For CWI generation look 
at the CWI Qty(s) first. If 
the populated use this qty. 
If the CWI Qty is not 
populated, use the Record 
Qty as the CWI Qty. 
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4.3.2 Configuration will use the quantities 
determined in preconfiguration. 

5. Performance Requirements: 

(list any performance 5. Performance should not be affected 

requirements associated with 
this change) 

[Identify system response 
requirements that must be 
met for user acceptance] 

6. Dependencies: 

(list any defects or features that 6. None 
this enhancement is dependent 
on or that will be dependent on 
this feature) 

7. Benefits: 

(provide benefits in dollars, 
reduced headcount, time 
savings, etc. for doing this 
work) [This is required to 
identify any savings that can 
be attributed this feature for 
securing budget approval] 

8. Affected Components: (Check) (Check) 

Yes No 



7. Enable the user to provide accurate contract billing expectations 
to the master contractors. Reduce the number of CIBEs generated by 
the contractor. 
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RTOC Instructions 

HELP 

User Guides 

Testing 

Infra-structure 

Management Reports 

Database 

9. Interfaces: 

(list any legacy or new 
interface systems impacted by 
this change) [Make sure other 
interface systems are aware 
of and agree with any 
requirement change that 
impacts them before 
proceeding] 

10. Work-around: 

(is there a temporary work 
around?) 

(describe work around in 
detail) 

[Also identify this in the 
OSPCM 'known problem' 
document] 

11. Risks: 

(list factors that impact, 
positive/negative, not doing 
this change) 

12. Business Rules: 



x 

X 
X 



X 
X 
X 



9. None 



(Check) 
Yes 



(Check) 
No 

X 



10. 



1 1 . OSPCM is producing inaccurate billing exceptions to the 
master contractors for PLAC2 work actions and for precast manholes in 
the 1995 regional contract. 
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(list any business rules or 
constraints that should apply. 
If business rules are included 
in the changes section, identify 
these with asterisk in bold, 
***business rule***) 



12. Always ignore the CWI Qty field when preconfiguring Telco 
substeps. 

CWI Qty can be greater than, less than, or equal to the Record Qty. 
CWI Qty cannot be "0" zero. 



13. Documentation Changes: 

(list affected documents 1 3 . On-line Help 

requiring change) User Guides 

[Documentation should 
prepare a checklist covering 
each document that must be 
updated for this feature] 



14. Special Training/Implementation Requirements: 

(list any special 14 Release Notes 

training/implementation 

required for this feature. 

Identify what will be required 

to train and implement this 

feature to the customer, i.e., by 

documentation, e-mail, help, 

cue cards, on sight training, 

etc.) 



15. Acceptance Criteria/Test Scenario: 

(list test scenarios required to 15. Test using the 1995 version of the master contract See Gail 

test change prior to user Deaton to set up Tables before testing 

acceptance, this can be updated 15.1 Enter a contractor substep on the Placing screen 

after the detailed design is WE= "A" Work Action = "PLAC" FRC= " 1 C" 

complemented.) REQUIRED Material Desc = "40-5" Record Qty = "1" Order Qty = "1" 

[Tester should prepare Verify that the CWI Qty in the CWI Information grid is enabled 

checklist based on these test Verify that the Depth, Width, Diameter, New/Existing is not 
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scenarios for documentation 
on results of tests. These 
should be in matrix from 
identified back to the 
numbering scheme use in 
these test scenarios] 



enabled. 

Verify a number can be entered in the CWI Qty. 
Enter "5" in CWI Qty 

Enter a "0". Verify that "0" cannot be entered. 

Blank out the field. Verify that the field can be blanked out. 

Save the substep. 

Configure. 

Go to the Contract Detail screen and verify 
CWI = "P001A" CWI = "1" 
CWI = "P405M" CWI = "1" 

1 5 .2 Enter a contractor substep on the Placing screen 
WE="A" Work Action = "PLAC" FRC="1C" 
Material Desc = "40-5" Record Qty = "1" Order Qty = "1" 

Verify that the CWI Qty in the CWI Information grid is 
enabled. 

Verify that the Depth, Width, Diameter, New/Existing is not 
enabled. 

Enter a "0". Verify that "0" cannot be entered. 

Blank out the field. Verify that the field can be blanked out. 

Enter "5" in CWI Qty 

Save the substep. 

Configure. 

Go to the Contract Detail screen and verify 
CWI = "P001B" CWI Qty = "5" 
CWI = "P405M" CWI Qty = "5" 

15.3 Enter a contractor substep on the Placing screen 
WE="B" Work Action = "PLAC2" FRC="45C" 

Material Desc = "ANMW-100" Record Qty = "1000" Order Qty = 
"1050" 

Verify that the CWI Qty in the CWI Information grid is 
enabled. 

Verify that the Depth, Width, Diameter, New/Existing is not 
enabled. 

Enter "950" in CWI Qty 
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Save the substep. 
Configure. 

Go to the Contract Detail screen and verify that the 
CWI = "C120A" CWI Qty = "950" 

15.4 Enter a contractor substep on the Placing screen WE= "B" Work 
Action = "FP" FRC= "45C" 

Material Desc = "MH-PC-6xl2xl2" Record Qty = "1" Order Qty = 

Verify that the CWI Qty in the CWI Information grid is 
enabled. 

Verify that the Depth, Width, Diameter, New/Existing is not 
enabled. 

Enter "864" in CWI Qty 
Save the substep. 
Configure. 

Go to the Contract Detail screen and verify that the 
CWI = "M03 IB" CWI Qty = "864" 
Enter a contractor substep on the Placing screen 
WE="B" Work Action = "PLAC" FRC="45C" 
Material Desc = "MH-PC-6xl2xl2" Record Qty = "1" Order Qty = 

Verify that the CWI Qty in the CWI Information grid is 
enabled. 

Verify that the Depth, Width, Diameter, New/Existing is not 
enabled. 

Save the substep. 
Configure. 

Go to the Contract Detail screen and verify that the 
CWI = "M030B" CWI Qty = "864" 
Enter a contractor substep on the Placing screen 
WE= "B" Work Action = "PLAC" FRC= "45C" 
Material Desc = "AMNW-100" Record Qty = "1860" Order Qty = 
"1900" 
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Verify that the CWI Qty in the CWI Information grid in 
enabled. 

Verify that the Depth, Width, Diameter, New/Existing is 
enabled. 

Verify that the Depth field has a default value. 

Check the default value. "24"should be entered if not default. 

Enter "1800" in CWI Qty 

Save the substep. 

Configure. 

Go to the Contract Detail screen and verify that the 
CWI = "C024B" CWI Qty = "1800" 
Enter a Telco substep on the Placing screen 
WE= "A" Work Action = "PLAC" FRC= "22C" 
Material Desc = "BKMA-100" Record Qty = "860" Order Qty = 
"900" 

Verify that the CWI Qty in the CWI Information grid is 
enabled. 

Verify that the Depth, Width, Diameter, New/Existing is not 
enabled. 

Save the substep. 
Configure. 

Go to the 207 Report in Job Entry and verify Record Qty and 
Order Qty. 

Enter a Telco substep on the Placing screen 

WE="A" Work Action = "PLAC" FRC="22C" 

Material Desc = "BKMA-100" Record Qty = "860" Order Qty = 

"900" 

Verify that the CWI Qty in the CWI Information grid is 
enabled. 

Verify that the Depth, Width, Diameter, New/Existing is not 
enabled. 

Enter a "0". Verify that "0" cannot be entered. 

Blank out the field. Verify that the field can be blanked out. 

Enter "100" in the CWI Qty 
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Save the substep. 
Configure. 

Go to the 207 Report in Job Entry and verify Record Qty and 
Order Qty. 

Go to substep in database and verify that "100" CWI Qty has been 
ignored. 



17. Attachments: 

(copies of screens, reports, etc. 16.1 None 
before and after proposed 
change - only identify if the 
customer requires the screen or 
something on the screen to 
look a certain way) 

Signatures of Agreement: 

(add additional rows if necessary) 
BAE: (on file) 6/9/98 

Lead Analyst: (on file) 6/9/98 
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BAE FUNCTIONAL DOCUMENT 

BAE Start Date: 01/28/1998 BAE Name: Gail W. Deaton 

BAE Comp. Date: 01/28/1998 BAE Tele. No.:2 05-977-3615 

BAE Hours: 2 LA Assigned: 

CMVC Component Name: je_ewo 
Associated Defect/Feature No.: 



Table # 7020A 



Target Release 
(give target release this 
needs to be in) [only 
identify if this is 
required for an 
emergency release or 
must be worked in 
next scheduled release] 



2.10 



Target Release Date: 

(give target release date 
for this enhancement, if 
required 



Priority: 

(provide priority from 'feature 
priority' list - number 
preliminary assigned by SME) 



Hi 



Revision No.: 
Reason for Revision: 



(B, C, etc. - this will require new signatures) 



General: 

(General Information - nothing 1 . The purpose of this document is to provide the customer's view of 
is to be typed here, this is for the functionality that needs to be changed or added to the existing 

OSPCM product. It is not the detail design requirements. It should 
concentrate of 4 what' is needed and not on the 'how' it is provided. 
2. All features that are >40 hours/ 1 business area require a structured 
inspection walk through process (currently using FAGAN). This is to 
be scheduled by the responsible SME for this feature with the testing 



information only about the 
functional spec process.) 
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team lead, documentation team lead and the IT development Managers. 
The IT development Managers will assign the appropriate 
representatives to attend the meeting. Th4ese inspections are not to 
inspect the author, they are to be used to understand the functionality 
required for development of the 'Detail Design Document'. 

3. The 'Analysis Phase Specific' checklist must be used, documented 
and baselined for each feature. 

4. Any correspondence associated with this feature should also be 
documented (i.e., impromptu meetings, phone conversations, etc.) and 
associated with the feature number. It should include time, date, and 
participants. 

5. Continue numbering scheme in your text input under each table to 
provide traceability for matrixes. 



1. Abstract: 

(brief description of 1.1 Make the default for the Est. Completion date in job_ewo 30 days 

change/addition from the current date. 

- This should pretty closely 
match the abstract in CMVC. 



2. Current Problem 

(brief description of what 2. 1 Currently the default for the Est. Completion date is today's date, 

system currently does, what Designers are not properly changing the date to a realistic date and 
needs to be changed, and why) today's date is being populated as the Est. Completion Date. When the 

job is FBRMed in Pricing and sent to BACAS the approval date is after 

the Est. Completion date. 

This is causing BSCAS errors to be generated. 



3. Proposed Solution: 

(brief description of what the 3.1 Make the default for the Est. Completion date in job_ewo 30 days 
system will or should do an from the current date. This should eliminate most of the BSCAS errors, 
any general constraints or 
conditions that limit the 
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solution) 



4. Change/Addition(s): 

(detailed description of 4.1 The estimated completion date currently defaults to the current 

change/addition) date. With this feature, this date will default to the current date + 30 

days. This will be the default for the creation of EWO and PWO jobs. 
In addition, when the user selects to clone a job, the estimated 
completion date will default to the current date + 30 days. The user can 
change the estimated completion date, but it must be the current date or 
a future date. 



5. Performance Requirements: 

(list any performance 5 . 1 

requirements associated with 
this change) 

[Identify system response 
requirements that must be 
met for user acceptance] 



6. Dependencies: 

(list any defects or features that 6.1 
this enhancement is dependent 
on or that will be dependent on 
this feature) 



7. Benefits: 

(provide benefits in dollars, 7.1 Eliminates BSCAS errors generated to the users. Savings in the 

reduced headcount, time time it takes to investigate and correct these errors. 

savings, etc. for doing this 

work) [This is required to 

identify any savings that can 

be attributed this feature for 

securing budget approval] 
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8. Affected Components: (Check) (Check) 

Yes No 



RTOC Instructions 
HELP 

User Guides 
Testing 
Infra-structure 
Management Reports 
Database 



9. Interfaces: 

(list any legacy or new 9.1 
interface systems impacted by 
this change) [Make sure other 
interface systems are aware 
of and agree with any 
requirement change that 
impacts them before 
proceeding] 



10. Work-around: 

(is there a temporary work 
around?) 

(describe work around in 
detail) 

[Also identify this in the 
OSPCM 'known problem' 
document] 



(Check) (Check) 
Yes No 

X 

10.1 



11. Risks: 

(list factors that impact, 11.1 User acceptance and BSCAS response, 

positive/negative, not doing 
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this change) 



12. Business Rules: 

(list any business rules or 12.1 
constraints that should apply. 
If business rules are included 
in the changes section, identify 
these with asterisk in bold, 
***business rule***) 

13. Documentation Changes: 

(list affected documents 13.1 
requiring change) 
[Documentation should 
prepare a checklist covering 
each document that must be 
updated for this feature] 

14. Special Training/Implementation Requirements: 

(list any special 14.1 

training/implementation 

required for this feature. 

Identify what will be required 

to train and implement this 

feature to the customer, i.e., by 

documentation, e-mail, help, 

cue cards, on sight training, 

etc.) 

15. Acceptance Criteria/Test Scenario: 

(list test scenarios required to 15.1 Enter a new EWO type job in job_entry. Check to make sure the 
test change prior to user estimated completion date default is 30 days from today, 

acceptance, this can be updated • Enter a new PWO type job in job_entry. check to make sure the 
after the detailed design is estimated completion date default is 30 days from today. 
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complemented.) REQUIRED 
[Tester should prepare 
checklist based on these test 
scenarios for documentation 
on results of tests. These 
should be in matrix from 
identified back to the 
numbering scheme use in 
these test scenarios] 



Test to see if the default date of 30 days from today can be changed 
to the current date or a future date. 

Select the refresh button, the estimated completion date should be 
reset to the current date + 30 days. 



17. Attachments: 

(copies of screens, reports, etc. 1 6. 1 
before and after proposed 
change - only identify if the 
customer requires the screen or 
something on the screen to 
look a certain way) 



Signatures of Agreement: 

(add additional rows if necessary) 
BAE: 

Lead Analyst: 
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BAE FUNCTIONAL DOCUMENT 



Table # 7046A 

BAE Start Date: 11/18/1997 BAE Name: Mark Seal 

BAE Comp. Date: 11/18/1997 BAE Tele. No.:2 05-977-3618 

BAE Hours: 8.5 LA Assigned: 

CMVC Component Name: sched 
Associated Defect/Feature No.: 



Target Release 
(give target release this 
needs to be in) [only 
identify if this is 
required for an 
emergency release or 
must be worked in 
next scheduled release] 



Target Release Date: 

(give target release date 
for this enhancement, if 
required 



Priority: 

(provide priority from 'feature SCHED 

priority' list - number # 1 
preliminary assigned by SME) 



Revision No.: 
Reason for Revision: 
General: 

(General Information - nothing 
is to be typed here, this is for 
information only about the 
functional spec process.) 



(B, C, etc. - this will require new signatures) 



1 . The purpose of this document is to provide the customer's view of 
the functionality that needs to be changed or added to the existing 
OSPCM product. It is not the detail design requirements. It should 
concentrate of 'what' is needed and not on the 'how' it is provided. 

2. All features that are >40 hours/1 business area require a structured 
inspection walk through process (currently using FAG AN). This is to 
be scheduled by the responsible SME for this feature with the testing 
team lead, documentation team lead and the IT development Managers. 
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The IT development Managers will assign the appropriate 
representatives to attend the meeting. Th4ese inspections are not to 
inspect the author, they are to be used to understand the functionality 
required for development of the 'Detail Design Document'. 

3. The 'Analysis Phase Specific' checklist must be used, documented 
and baselined for each feature. 

4. Any correspondence associated with this feature should also be 
documented (i.e., impromptu meetings, phone conversations, etc.) and 
associated with the feature number. It should include time, date, and 
participants. 

5. Continue numbering scheme in your text input under each table to 
provide traceability for matrixes. 



1. Abstract: 



(brief description of 

change/addition 

- This should pretty closely 



1 . 1 Provide the user the ability to choose range of weeks to be 
displayed on the scheduling screen. 



match the abstract in CMVC. 



2. Current Problem 



(brief description of what 
system currently does, what 
needs to be changed, and why) 



2.1 Currently the system may not be able to display a 20 week schedule 
due to the large number of jobs in a particular CMC. 



3. Proposed Solution: 

(brief description of what the 
system will or should do an 
any general constraints or 



3.1 When the user enters the scheduling module the system should ask 
the user to enter range of weeks of scheduled work to be displayed. 



conditions that limit the 



solution) 



4. Change/Addition(s): 

(detailed description of 
change/addition) 



4.1 When the user enters the scheduling module, the scheduling desk 
top should be displayed. The following tool bar buttons should be 
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active. 

20 week limited 
20 week unlimited 
current week 
next week 
activity mtce 
reports 

4.2 When the user selects the 20 week limited schedule button from the 
desk top tool bar, the system will display a dialog box asking the user to 
enter a range of weeks to be displayed. The maximum range that the 
user can request is 1 to 20 weeks. The system will try to display the 
requested range of weeks of data. If there is too much data to be 
displayed then the system will display a message tot he user saying that 
there is too much data to be displayed at once. The system will prompt 
the user to enter a range of weeks again. If the user requests only one 
week of data and the system determines that there is too much data to 
be displayed then the system will display a message that says that there 
is too much data to be displayed for the week requested. When the user 
clicks OK then the system should display as much data as possible. 

4.3 when the user selects the 20 week unlimited schedule button from 
the desk top tool bar, the system will display a dialog box asking the 
user to enter a range of weeks to be displayed. The maximum number 
that the user can request is 1 to 20 weeks. The system will try to 
display the requested range of weeks data. If there is too much data to 
be displayed then the system will display a message to the user saying 
that there is too much data to be displayed at once. 

The system will prompt the user to enter a range of weeks again. If the 
user requests only one week of data and the system determines that 
there is too much data to be displayed then the system will display a 
message that says that there is too much data to be displayed for week 
requested. When the user clicks OK then the system should display as 
much data as possible. 

4.4 When the user selects the Current week button the desk top tool 
bar, the system will only display week 1 data. If the system determines 
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that there is too much data to be displayed then the system will display 
a message that says that there is too much data to be displayed for week 
1 . when the user clicks OK then the system should display as much 
data as possible. 

4.5 When the user selects the Next week button from the desk top tool 
bar, the system will only display week 2 data, if the system determines 
that there is too much data to be displayed then the system will display 
a message that says there is too much data to be displayed for week 2. 
When the system should display as much data as possible. 

4.6 When the user selects the Activity Mtce button from the desk top 
tool bar then the system will display a dialog box allowing the user to 
type in the Job name. This is the same dialog box that currently exists 
in scheduling. 

4.7 Reports button on the desk top tool bar will be active so that a user 
can select an available report to be printed even though a schedule 
screen is not displayed. 

5. Performance Requirements: 

(list any performance 
requirements associated with 
this change) 

[Identify system response 
requirements that must be 
met for user acceptance] 

6. Dependencies: 

(list any defects or features that 
this enhancement is dependent 
on or that will be dependent on 
this feature) 

7. Benefits: 

(provide benefits in dollars, 
reduced headcount, time 
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5.1 By limiting the amount of data requested to be displayed the system 
should not be displaying buffer overload errors. By only displaying the 
requested range of weeks of scheduling data. . ..performance should 
increase because the user will likely request less data than is being 
displayed today. 



6.1 NONE 



7.1 Benefits are that the users will see improved performance because 
the system is handling and displaying less data. 



savings, etc. for doing this 
work) [This is required to 
identify any savings that can 
be attributed this feature for 
securing budget approval] 

8. Affected Components: (Check) (Check) 

Yes No 



RTOC Instructions x 

HELP x 

User Guides x 

Testing x 

Infra-structure 

Management Reports 

Database 



9. Interfaces: 

(list any legacy or new 9.1 N/A 

interface systems impacted by 

this change) [Make sure other 

interface systems are aware 

of and agree with any 

requirement change that 

impacts them before 

proceeding] 

(Check) 
No 

X 



(Check) 

10. Work-around: Yes 

(is there a temporary work 
around?) 

(describe work around in 10.1 
detail) 

[Also identify this in the 
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OSPCM 'known problem' 
document] 



11. Risks: 

(list factors that impact, 11.1 Some users can't see the scheduling data at all and others will be 

positive/negative, not doing in the same situation as volumes increase, 
this change) 



12. Business Rules: 

(list any business rules or 12.1 See Changes 

constraints that should apply. 

If business rules are included 

in the changes section, identify 

these with asterisk in bold, 

***business rule***) 



13. Documentation Changes: 

(list affected documents 13.1 User guides, Help 

requiring change) 

[Documentation should 

prepare a checklist covering 

each document that must be 

updated for this feature] 



14. Special Training/Implementation Requirements: 

(list any special 14. 1 Release notes, User Guides and Release notes will document the 

training/implementation changes. 

required for this feature. 

Identify what will be required 

to train and implement this 

feature to the customer, i.e., by 

documentation, e-mail, help, 

cue cards, on sight training, 
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etc.) 



test change prior to user 
acceptance, this can be updated 
after the detailed design is 
complemented.) REQUIRED 
[Tester should prepare 
checklist based on these test 
scenarios for documentation 
on results of tests. These 
should be in matrix from 
identified back to the 
numbering scheme use in 
these test scenarios] 



15. Acceptance Criteria/Test Scenario: 

(list test scenarios required to 15.1 Verify that when entering the scheduling module, the scheduling 

desk top is displayed. The following tool bar buttons will be active. 
20 week limited 
20 week unlimited 
current week 
next week 
activity mtce 
reports 

15.2 20 week limited 
Select the 20 week limited schedule button from the desk top tool 
bar, the system will display a dialog box asking the user to enter a 
range of weeks to be displayed. Verify that the maximum number 
that the user can request is 1 to 20 week range. 
Verify that any range combination from 1 to 0 can be requested. 
Verify that when too much data exists to be displayed that the 
system displays a message saying that there is too much data to be 
displayed at once. 

Verify that the system prompts the user to enter the range of weeks 
request again. 

Verify that when the user requests only one week of data and the 
system determines that there is too much data to be displayed that 
the system will display a message that says that there is too much 
data to be displayed for week 1 . 

Click OK and the system should display as much data as possible. 

15.3 20 week unlimited 
Select the 20 week Unlimited schedule button from the desk top 
tool bar, the system will display a dialog box asking the user to 
enter a range of weeks to be displayed, verify that the maximum 
number that the user can request is 1 to 10 weeks. 
Verify that when too much data exists to be displayed that the 
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system displays an message saying that there is too much data to be 
displayed at once. 

Verify that the system prompts the user to enter the range of weeks 
requested again. 

Verify that when the user requests only one week of data and the 
system determines that there is too much data to be displayed that 
the system will display a message that says that there is too much 
data to be displayed for week. 

Click OK and the system should display as much data as possible. 

15.4 Current week Button 

• Verify that when the user selects the Current week button from the 
desk top tool bar, the system will only display week 1 data. 

• Verify that when the system determines that there is too much data 
to be displayed that the system will displays a message that says 
there is too much data to be displayed for week 1 . 

• Verify that when the user clicks OK then the system should display 
as much data as possible. 

15.5 Next Week Button 

• Verify that when the user selects the Next week button from the 
desk top tool bar, the system will only display week 2 data. 

• Verify that when the system determines that there is too much data 
to be displayed that the system will displays a message that says 
there is too much data to be displayed for week 2. 

• Verify that when the user clicks OK then the system should display 
as much data as possible. 

15.6 Activity Mtce Button 

• Verify that the user selects the Activity Mtce button from the desk 
top tool bar then the system will display a dialog box allowing the 
user to type in the Job name. 

15.7 Reports button 

• Verify that the report button on the desk top tool bar will be active 
so that a user can select an available report to be printed even 
through a schedule screen is not displayed. 
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15.8 Verify that when any schedule is displayed that all existing too bar 
functionality works as it does today. 

17. Attachments: 

(copies of screens, reports, etc. 1 6. 1 NONE 

before and after proposed 

change - only identify if the 

customer requires the screen or 

something on the screen to 

look a certain way) 

Signatures of Agreement: 

(add additional rows if necessary) 
BAE: 

Lead Analyst: 
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BAE FUNCTIONAL DOCUMENT 



Table # 6723A 



BAE Start Date: 



07/11/1997 



BAE Name: 



Larry Rice 



BAE Comp. Date: 



08/04/1997 



BAE Tele. No.:977-7436 



BAE Hours: 



49 



LA Assigned: 



CMVC Component Name: 



Job Entry 
Job Entry Other 
Billing & Reporting 
Management Reports 



Associated Defect/Feature No.: 



Target Release 

(give target release this 
needs to be in) [only 
identify if this is 



Target Release Date: 

(give target release date 
for this enhancement, if 
required 



required for an 
emergency release or 
must be worked in 
next scheduled release] 

Priority: 

(provide priority from 'feature 
priority 5 list - number 
preliminary assigned by SME) 

Revision No.: (this will require new signatures) 

Reason for Revision: 



General: 



(General Information) 



1. All features that are >40 hours/1 business area require a structured 
inspection walk through process (currently using FAGAN). This is to 
be scheduled by the responsible SME for this feature. 



2. The 'Analysis Phase Specific' checklist must be used, documented 
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and baselined for each feature. 

3. Any correspondence associated with this feature should also be 
documented (i.e., impromptu meetings, phone conversations, etc.) and 
associated with the feature number. It should include time, date, and 
participants. 



1. Subject: 

(brief description of change) 



1 . The creation of an mechanized Pitlog that would track the life cycle 
of a pit request for both an Engineering Work Order (EWO) and 
Routine Work (RW). This process would address the request for 
both planned (Exhibit "A") and demand (Exhibit "B") pits. The 
Pitlog would provide a mechanized request tot he contractor to 
open and to close a pit, and provide OpenMail notification o Telco 
when the contractor has opened a planned pit. The process would 
also create an Open Pitlog Report, Pending Open Request 
Report and a Pending Closed Report that could be utilized by 
both Telco and contractor. 

2. The regional standard developed for mechanized Pitlog must be 
followed if this process is to function correctly. 



2. Introduction: 

(description of what system 
currently does, what needs to 
be changed, and why) 



1 . Currently the system allows the user to input work tasks that can be 
defined as a pit in user terms. These are identified for EWO's in JE 
with the work action of DIG that configures the substep with the 
CWI for open/close a pit. For RW's, the user identifies these work 
tasks by using one of three work actions of PIT, OPIT & CPIT. 
The user provides the CWI appropriate for the work requested 
either Exhibit "A" or Exhibit "B'\ 

2. The application lacks a process that would track these work task 
requests identified by the user as a pit. The application does not 
have a process in place that would completely track the life cycle 
for a "pit request". This cycle includes: (1) Identify the need for a 
pit and provide contractor expectations, (2) Telco request to the 
contractor to open a pit, (3) actual date the contractor opened the 
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pit, (4) the Telco request to the contractor to close the pit, and (5) 
the actual date the contractor closed the pit. 

3. Process should minimize the coding changes required for JE & JEO 
by utilizing the existing M&P for encoding and requesting both 
planned (Exhibit 'A') and demand (Exhibit 'B') pits. 

4. The Pitlog process will use the initial data entered in Job Entry for 
EWO's and Job Entry Other for RW's (Process #1), mechanize the 
communication of the "Telco Open Pit Request" to the contractor 
(Process #2), mechanize the "Contractor Open Pit" notification 
(OpenMail) to Telco that the pit was actually opened (Process #3), 
mechanize the "Telco Close Pit Request" to the contractor (Process 
#4), and if the user elects not to use the Pitlog process, then this 
process would not affect the existing Billing & Reporting process 
of substep completions by the contractor. (Process #5). 

5 . The intent is that the data entry required to provide the contractor 
billing expectations and pit request be performed only once. For 
example, if the "Desired Work Date" was entered in JEO that the 
application would populate the "Telco Requested Open Pit Date" in 
the Pitlog for a demand (Exhibit "B") pit. And upon completion by 
the contractor in B&R-Completions that the application would 
populate the "Contractor Actual Close Date' in the Pitlog. 

Work flow of Pit Request for Planned Work Exhibit "A" 
EWO/PWO: Having the designed work encoded in JE, the Telco 
supervisor has all of the work locations identified that require a pit. The 
expectations for each job have been provided to the contractor by the 
MP-10484 Engineering Work Order. However, the contractor has 
not been notified when actually open the pit substep. 
Once the EWO/PWO job has been scheduled and requires that a pit be 
opened, the Telco Supervisory will access B&R-Open-Pitlog-Telco 
Open Pit Request and select from the grid the job that Telco wants to 
have a pit substep opened. The Telco supervisor will populate the 
"Telco Open Pit Request Date" field with the date that the pit is to be 
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opened by. 

RW: The same process for an EWO Exhibit "A" pit can also be 
utilized for RW planned pits. Otherwise, Telco has the option of 
populating the "Desired Work Date" in JEO at the time the RW substep 
(PIT) is created. Either method will generate notification to the 
contractor in the same manner discussed next. 

This transaction will create an "Open Pit Request" for the contractor 
in B&R-New Work the next time the contractor requests their New 
Work Orders. This will be considered the mechanized request to the 
contractor to open a pit. 

Once the contractor has completed opening the pit substep requested, 
they will select B&R-Open Pitlog-Contractor Open Pit Update and 
populate the "Contractor Open Pit Date" field with the actual date the 
pit substep was opened in the field. 

This transaction will then create a notification for each pit that was 
opened by the contractor and will be OpenMail to the Telco RESID 
assigned to that substep. This will be considered the mechanized 
notification from the contractor to Telco that the pit has been opened 
and ready for Telco forces to work. 

After the technician has completed the work operation associated with 
the pit request, he/she will notify their supervisor that the pit is ready to 
close. 

The Telco Supervisor will then access B&R-Open-Pitlog-Telco Close 
Pit Request and select from the gird the job that he/she wants to have 
the pit closed. The Telco Supervisor will populate the "Telco Close Pit 
Request Date" field with the current date or the date the pit can be 
closed by the contractor. 

This transaction will create a "Close Pit Request" for the contractor in 
B&R-New Work the next time the contractor requests their New Work 
Orders. This will be considered the mechanized request to the 
contractor to close a pit. 

Once the contractor has completed closing the pit substep requested, 
they will select B&R-Completions and populate the data as they are 
currently doing today for substep completions. The B&R application 
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i 



will populate the "Contractor Closed Pit Date" field in the Pitlog. 
With the data entered, the following reports would be available for both 
the contractor and Telco that will track the planned pits: 

• The Open Pitlog Report will provide the complete status of each 
pit that has opened by the contractor. 

• The Pending Open Request Report will provide a list and status 
of all pit that had been requested by Telco and have not been 
reported open by the contractor. 

• The Pending Close Request Report will provide a list and status 
of each pit that have been requested to closed by Telco but have not 
been completed by the contractor. 

Work Flow of Pit Request for Demand Work (Exhibit "B") 
Having encoded the demand wok in JEO, the Telco supervisor has 
request that a contractor be dispatched on an Exhibit "B" hourly rate to 
dig at a specific location that will result in a pit being left open. 
When Telco generates the initial request using the work action of 
OPIT, Telco will populate the "Desired Work Date" in JEO. This 
makes the substep available to the contractor and an generates an 
existing MP-10482 Routine Work Order for the contractor as his 
billing expectations. This becomes mechanized request then populate 
the "Telco Open Pit Request Date" field in the Pitlog for this RW step 
(RW steps that have a OPIT & CPIT substep will be reflected in Pitlog 
as one pit location as a step). 

Telco knows that a pit will be left open at this location and created a 
second substep on the same step using the work action of CPIT for 
either Exhibit "B" or Exhibit "A' CWFs to have the pit closed. Telco 
does not populate the "Desired Work Date" at this time. 
Once the contractor has completed this request (CPIT substep) in B7R- 
Completions, the system will populate the "Contractor Open Pit Date" 
in the Pitlog. 

Once the Telco work operation has been completed for this RW request, 
the Telco technician will notify his/her supervisory that this location 
needs to be closed. 

At this time, Telco will populate the "Desired Work Date" in JEO for 
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the second substep on the same step, where the work action is CPIT, 
with the current date or the date Telco wants this location closed. This 
makes this substep available to the contractor and generates an existing 
MP-10482 Routine Work Order for the contractor and his billing 
expectations. This becomes the mechanized request to the contractor to 
close a pit on Exhibit C B' hourly cost or Exhibit 'A' unit price. 
The process will also populate the "Telco Close Pit Request Date" field 
in the Pitlog for this RW step (RW steps that have a OPIT & CPIT 
substep will be reflected in Pitlog as one pit location as a step). 
Again once the contractor completes the second substep of CPIT and 
the system will populate the "Contractor Closed Pit Date" in Pitlog. 
With the data entered the following reports would be available for both 
the contractor and Telco that will track the demand pits: 

• The Open Pitlog Report will provide the complete status of each 
pit that has been opened b the contractor. 

• The Pending Open Request Report will provide a list and status 
of all pit that had been requested by Telco and have not been 
reported open by the contractor. 

• The Pending Close Request Report will provide a list and status 
of each pit that have been requested to closed by Telco but have not 
been completed by the contractor. 

1 . A new pitjog table will be crated to record the transactions that 
will enable the user to track the pit request from start to finish. 

2. The pit_Jog table will populated by the initial entry in Job Entry 
Other for RW Exhibit 4 A' unit price planned pits. 

3. The pitjog table will populated by the initial entry in Job Entry 
Other for RW Exhibit 'A' unit price planned pits, and RW & EWO 
Exhibit 'B' hourly cost demand pits. 

3.1 The application will identify demand pits at a step level 
with an OPIT & CPIT substep. 

3.2 The process will create only one pitjog record for a step 
that has OPIT & CPIT substep. 

4. The M&P developed would allow those substeps identified by the 
four work actions of DIG, PIT, OPIT & CPIT to be tracked in the 
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Pitlog. 

5. The updates form the new Pitlog selection in Billing & Reporting 
will populate the dates for: 

5 . 1 Telco Open Pit Request Date 

5.2 Contractor Open Pit Date 

5.3 Telco Close Pit Request Date 

6. With the completion of the substep in B&R-Completions by the 
contractor, this process will populate the date for: 

6. 1 Contractor Close Pit Date 



7. Regional Standard for Pits in JE & JEO 

7.1 . Planned Pits (Exhibit <A'Y For EWO pit substeps, these pit 
locations will be requested to be open & closed in the 
new Pitlog. For RW pit locations, the user will have the 
option of populating the "Desired Work Date" when the 
RW is being keyed in JEO. Or the user may elect to 
populate the "Telco Open Pit Request Date" in the new 
Pitlog. Either scenario will produce the same result. 
Both EWO & RW planned pits and will be tracked on 
three new Pitlog Reports. 

7.1.1 Job Entry (JE) - Exhibit 'A': The job entry 
configuration currently uses the work action of 
DIG to configure substeps for Exhibit 'A' CWFs 
to open/close a pit. No changes would be 
required for this process. 

7. 1 .2 Job Entry Other (JEO) 6 A': For those locations 
(substeps) that a pit is to be open/close on Exhibit 
'A' CWFs for Routine Work, the work action 
PIT must be used on each substep. 

7. 1 .2. 1 For RW planned pits, the Pitlog process 
will track these requests at a step level. 

7.1.2.2 If there are to be multiple pits opened on 
for this RW then each pit must be created 
on a separate step. This provides the 
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unique location/address for each pit 
request. 

7.1.3 Both of these transactions will create an 
occurrence in the pitlog for each request. 
7.2 Demand Pits (Exhibit 'B') : These pit substeps will not 
be requested to be open & closed in the new Pitlog, but 
will be tracked on the three new Pitlog Reports. The 
normal process of populating the substep JEO-Desired 
Work Date for both the OPIT & CPIT substeps will 
make this work available to the contractor. 
7.2.1 Job Entry Other (JEO) - Exhibit 'B' : For 
those locations (substeps) were a pitlog was 
requested to be opened on Exhibit "B" CWI's the 
work action OPIT is used. The user will then 
create a second step using the work action CPIT 
to have the pit closed on either Exhibit 'B' hourly 
cost or Exhibit 6 A' unit price. 

8. For those planned substeps that have been identified as EWO/PWO 
Exhibit 'A' unit price pits (DIG), and RW Exhibit 'A' unit price 
pits (PIT), Telco will use the Pitlog to generate MP - ?????? Open 
Pit Request work orders. These work orders will appear in B&R- 
New Work for the contractor to use for their employees dispatch 
ticket. 

9. For RW Exhibit 'A' unit price pits (PIT), Telco also the option of 
populating the "Desired Work Date" in JEO at the time Telco 
creates the RW Exhibit 'A' request. The process will generate a 
"Pit Request Work Order" in lieu of the MP - 10482 Routine Work 
Order. 

10. For those demand substeps that have been identified as EWO or 
RW Exhibit 'B' hourly cost pits (OPIT/CPIT), Telco will continue 
to use the existing method of populating the "Desired Work Date' 
in JEO for each substep when Telco wishes to make the work 
available to the contractor. 

1 1 . This process will continue to provide billing expectations, the 
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"Who, What, Where, When and Why" required for the contractor 
for Exhibit 'B' expenditures by the "MP-10482 Routine Work 
Order". 

12. By using this methodology, all substeps identified as pits will be 
tracked on the following three new Pitlog Reports: Open Pitlog 
Report, Pending Open Request Report and Pending Closed 
Request Report that can be utilized by both Telco and contractor 



4. Change(s): 

(detailed description of 
change) - 

[add additional rows if 
multiple changes] 



1 . Data Input 

1.1 EWO/PWO: User enters a Exhibit 'A' substep_ewo 
where the work action equals DIG in JE. When the 
application creates, configures and saves the 
substep_ewo record, the application will create a new 
pitjog record linking it to the original substep_ewo. 

1 .2 RW Exh-A: User creates substeprw for Exhibit 
'A' where the work action equals PIT in JEO When 
the application saves the substep_rw record the 
application will create a new pit log record linking it to 
the original substep_rw. 

1 .2. 1 If the user elects to populate the "Desired Work 
Date" in JEO the application will populate the 
"Telco Requested Open Date' field on the 
pitjog record. 

1 .3 RW Exh-B: User creates the first substep rw where 
the work action equals OPIT and the second substep 
where the work action equals CPIT in JEO. When the 
application saves the substep rw record, the application 
will also create a new pitjog record linking it to the 
original OPIT substep_rw. The application will create 
only one occurrence of pit)log for this step_rw. 

1.3.1 When Telco populates "Desired Work Date" 
for the OPIT substep in JEO, the application 
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will populate "Telco Requested Open Date" on 
pitjog record. 
1 .3.2 When Telco populates "Desired Work Date" 
for the CPIT substep in JEO, the application 
will populate "Telco Requested Close Date" on 
pitjog record. 

1 .4 EWO Exh-B: User creates the first substep_ewo 
where the work action equals OPIT and the second 
substep where the work action equals CPIT in JEO. 
when the application saves the substepewo record, the 
application will also crate a new pitjog record linking 
it to the original OPIT substep_ewo. The application 
will create only one occurrence of pit log for this 
stepewo. 

1 .4. 1 When Telco populates "Desired Work Date" 
for the OPIT substep in JEO, the application 
will populate 'Telco Requested Open Date' on 
pitjog record. 

1 .4.2 When Telco populates "Desired Work Date" 
for the CPIT substep in JEO, the application 
will populate "Telco Requested Close Date" on 
pitjog record. 

1 .5 The new pit record may require an accepted_ind for 
this table to ensure not sending multiple request to the 
contractor. 

1 .6 Once the pit substep has been successfully encoded in 
either JE or JEO, the application will have created a 
corresponding pit log record for each of these pit 
substeps and steps that have the work action equal to 
DIG for EWO/PWO Exhibit £ A\ PIT for RW Exhibit 
' A\ and one for a step_rw where there is a step with 
two substeps of OPIT & CPIT for RW/EWO Exhibit 
'B\ The assumption is that there is now a 
corresponding pitjog record for each substep 
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identified in the JE & JEO requiring a pit. 

1 .7 The contracts for JE & JEO will require modification. 

1.8 Only those sub steps that follow the regional 
standard for encoding of a pit will have a presence 
in the pit_log table and therefore be considered to 
tract on the Pitlog Reports. 

2. Billing & Reporting 

This application will require a new entry of Pitlog in the 
"Open" drop down menu. Upon selection of Pitlog, a new drop 
down menu will populate with the following selections and 
functions: (See Fig. 17). 

2.1 Telco Open Pit Request. . . 

2.1.1 This selection will allow Telco to request a pit 
to be opened in the Pitlog for planned pits. The 
selection criteria are State & CMC, RESID, or 
Job Number. 

2. 1 .2 Telco populates Cont#, State, CMC and RESID 
to selected all planned pit substeps 
(EWO/PWO & RW) for the selection criteria 
provided. 

2.1.3 If the user does not populate RESID, then the 
application would populate the grid with all pit 
substeps where the "Telco Requested Open" 
date was not populated and that are assigned to 
this RESID. 

2. 1 .4 If the user does populate RESID, then the 
application would populate the grid with all pit 
substeps where the "Telco Requested Open" 
date was not populated for the entire CMC. 

2.1.5 The user can then select from the grid the jobs 
that Telco wanted to request from the pit 
substep be opened. (See Fig. 1 8) 
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2.1.6 Once these jobs have been selected, a drop 
down box listing the jobs selected with the 
corresponding print and step information will 
be provided. (See Fig. 19) 

2.1.7 The user then is placed on a grid that displays 
Job, Print, Step and Substep Information of the 
Job, Print & Step that was selected. 

2.1.8 The user will populate the "Telco Requested 
Open" date field. 

2. 1 .9 This will generate a MP-????? Open Pit 
Request for the contractor in the B&R-New 
Work Orders presentation to have the pit 
substep opened. 

2.1.10 The 'Telco Open Pit Request Date" is for only 
Telco to populate. (See Fig. 20) 

2.1.11 when Telco populates the JEO-Desired Work 
Date for RW Exhibit 'A' planned pits or RW & 
EWO Exhibit 'B' demand pits, the system will 
populate these dates in the Pitlog. 

2.1.12 If Telco where to request on of the demand pit 
jobs, then the dates would be reflective in the 
Pitlog. 

2.2 Contractor Receives Open Pit Request 

2.2. 1 When the contractor accesses B7R- 
Completions-New Work, the gird will include a 
new column for PIT that will enable the 
contractor to identify his pit requests. 

2.2.2 The processes by which the contractor will 
receive their planned EWO/PWO & RW 
Exhibit 'A' unit price pit requests to open a pit 
will utilize the existing procedure of making 
them available in the B&R-New Work. (See 
Fig. 21) 



Exh. 2 - Page 342 



2.2.3 The contractor will receive the new "MP-???? 
Open Pit Request: for all planned pit substeps 
that have been requested to be open by Telco. 

2.2.4 The process by which the contractor will 
receive their demand EWO & RW Exhibit 4 B' 
hourly cost pit requests to open a pit will utilize 
the existing procedure of making them 
available in the B&R-New Work. 

2.2.5 The contractor will continue to receive the MP- 
10482 Routine Work Order that will provide 
the request for the OPIT substeps. 

2.3 Contractor Open Pit Update... 

2.3.1 This selection allows the contractor to populate 
the date the contractor actually opened the pit 
that had been request to open in Pitlog for 
planned pits. 

2.3.2 For demand pits, the B&R-Completions dates 
are reflected in the Pitlog for these pit requests. 

2.3.3 The contractor selects the "Contractor Open Pit 
Update: selection that will list all jobs that have 
a pending "Telco Open Pit Request" in the 
Pitlog. (See Fig. 22) 

2.3.4 The contractor selects the jobs that are to be 
populated with the date they where actually 
opened in the. 

2.3.5 Once these jobs have been selected a drop 
down box listing the jobs selected with the 
corresponding print and step information will 
be provided. (See Fig. 23) 

2.3.6 The contractor is placed on a grid that 
displaysJob, Print, Step and Substep 
information. 
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2.3 .7 The contractor will populate the "Contractor 
Open Pit" date with the date that the pit was 
actually opened in the field. 

2.3.8 This will generate a OpenMail notification for 
planned pits to the owner (RESID) of the 
substep. This will be the notification from the 
contractor to Telco that the pit is open and 
ready to be worked by Telco forces. 

2.3.9 The "Contractor Open Pit Date" is only to be 
populated by the Contractor. (See Fig. 24) 



2.4 Telco Close Pit Request... 

2.4. 1 This selection will allow Telco to Request a 
planned pit to be closed in the Pitlog. 

2.4.2 Telco populates State & CMC, RESID or Job 
Number to select all substeps (EWO/PWO & 
RW) for the selection criteria provided 

2.4.3 If the user does populate RESID then the 
application would populate the grid with all 
pits substeps where the "Contractor Open Pit" 
date is populated and that are assigned to this 
RESID. 

2.4.4 If the user does not populate RESID then the 
application would populate the grid with all 
pits substeps where the 'Contractor Open Pit" 
date is populated for the entire CMC. 

2.4.5 The user will then select from the grid the jobs 
that Telco wants to request the pit to be closed. 
(See Fig. 25) 

2.4.6 Once these jobs have been selected, a drop 
down box listing the jobs selected with the 
corresponding print and step information. (See 
Fig. 26) 
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2.4.7 The user then is placed on a grid that displays 
Job, Print, Step and Substep information. 

2.4.8 The user will populate the "Telco Requested 
Close" date field for planned pits. 

2.4.9 This will generate a MP-????? Close Pit 
Request for the contractor in the B&R-New 
Work Order presentation to close the pit. 

2.4. 1 0 The "Telco Close Pit Request Date" is for only 
Telco to populate. (See Fig. 27) 

2.5 Contractor Receives Close Pit Request 

2.5.1 The contractor will access B&R-Completions- 
New Work. The grid can include a new 
column for PIT that will enable the contractor 
to identify his pit requests. 

2.5.2 The process by which the contractor will 
receive their planned EWO/PWO & RW 
Exhibit ' A' unit price pit requests to have a pit 
closed will utilize the existing procedure of 
making them available in their New Work. 
(See Fig. 28) 

2.5.3 The contractor will receive the new "MP- 
????? Close Pit Request" for all planned pit 
substeps that have been requested to be open 
by Telco. 

2.5 .4 The process by which the contractor will 
receive their demand EWO & RW Exhibit C B' 
hourly cost pit requests to open a pit will utilize 
the existing procedure of making them 
available in the B&R-New Work. 

2.5.5 The contractor will continue to receive the MP- 
10482 Routine Work Order that will provide 
the request for CPIT substeps. 

2.6 Open Pit Report... 

2.6.1 This will generate a Crystal report that will list 
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all pit substeps that are open for the selection 
criteria provided by the user. 

2.6.2 The selection criteria is State, CMC, and Cont# 
with the RESID optional. This will allow the 
user to request this report for an individual 
RESID instead of for the entire CMC. 

2.6.3 This report will reflect the status of all pit 
substeps that have a "Contractor Open Pit" date 
populated. 

2.6.4 The "days" column of the report calculates the 
number of days a pit has been open (Today- 
Contractor Open Pit Date) 

2.6.5 This report will be made available to both 
Telco and contractor. 

2.7 Pending Open Request Report. . • 

2.7. 1 This will generate a Crystal report that will list 
all pit substeps that have been requested to be 
open for the selection criteria provided by the 
user. 

2.7.2 The selection criteria is State, CMC, and Cont# 
with the RESID optional. This will allow the 
user to request this report for an individual 
RESID instead of for the entire CMC. 

2.7.3 This report will reflect the status of all pit 
substeps that have a "Telco Open Pit Requested 
Date" populated and the "Contractor Open Pit 
Date" has not been populated. 

2.7.4 The 'days' column of the report calculates the 
number of days from when the pit was 
requested to be opened (Today-Telco Open Pit 
Request Date). 

2.7.5 This report will be made available to both 
Telco and contractor. 
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2.8 Pending Close Request Report... 

2.8.1 This will generate a Crystal report that will list 
all pit substeps that have been request to be 
closed for the selection criteria provided by the 
user. 

2.8.2 The selection criteria is State, CMC, and Cont# 
with the RESID optional. This will allow the 
user to request this report for an individual 
RESID instead offer the entire CMC. 

2.8.3 This report will reflect the status of all pit 
substeps that have a "Telco Close Pit 
Requested Date' populated and the "Contractor 
Closed Pit Date" has not been populated. 

2.8.4 The "days" column of the report calculates the 
number of days from when the pit was 
requested to be closed (Today - Telco Close 
Pit Request Date) 

2.8.5 This report will be made available to both 
Telco and contractor. 

OTjVMM *.»«»»* • 
»♦>*.*■»< •» 
MM WW mm+f* * 

I>«MM> * 

V'4M*w * 

5. Performance Requirements: 

(list any performance 1 . Should not affect performance, 

requirements associated with 
this change) 

[Identify system response 
requirements that must be 
met for user acceptance] 

6. Dependencies: 
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(list any defects or features that 1 . None 
this enhancement is dependent 
on or that will be dependent on 
this feature) 



7. Benefits: 

(provide benefits in dollars, 
reduced headcount, time 
savings, etc. for doing this 
work) [This is required to 
identify any savings that can 
be attributed this feature for 
securing budget approval] 



Eliminates manual log kept by most Telco supervisors in the 
field. 

Mechanizes the request process for Exhibit 'A' planned pits to 
the contractor for opening and closing request. 
Provides positive notification to Telco when the contractor has 
opened an Exhibit 'A' planned pit. 



8. Affected Components: 



(Check) 



Yes 



(Check) 



No 



RTOC Instructions 

HELP x 

User Guides x 

Testing x 

Infra-structure x 

Management Reports x 

Database x 



9. Interfaces: 

(list any legacy or new 1 . None 

interface systems impacted by 

this change) [Make sure other 

interface systems are aware 

of and agree with any 

requirement change that 

impacts them before 



Exh. 2 - Page 348 



proceeding] 



(Check) (Check) 
10. Work-around: Yes No 

(is there a temporary work x 
around?) 

(describe work around in 1 . 

detail) 

[Also identify this in the 
OSPCM 'known problem' 
document] 



1 . (-) Will require the Telco supervisor to maintain a manual 
Pitlog. 

2. (+) Provides a mechanized pitlog for a CMC or specific 
RESED. 

3. (-) Requires Telco to continue to make manual request to have 
an Exhibit 'A' planned pit opened or closed. 

4. (+) Provides a mechanized way of requesting the opening and 
closing of Exhibit 'A' Planned pits for the contractor. 

5. (+) Provides positive notification to Telco when the Exhibit 'A' 
planned pit has been opened. 



11. Risks: 

(list factors that impact, 
positive/negative, not doing 
this change) 



12. Business Rules: 

(list any business rules or 1 . 

constraints that should apply) 



See text provided 



13. Documentation Changes: 
(list affected documents 
requiring change) 
[Documentation should 
prepare a checklist covering 
each document that must be 



User Guides 

1.1 Job Entry 

1.2 Job Entry Other 

1.3 Billing & Reporting 
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updated for this feature] 



14. Special Training/Implementation Requirements: 

(list any special training 1 . 

required for this feature, i.e., 
documentation, e-mail, help, 
cue cards, on sight, etc.) 

15. Acceptance Criteria/Test Scenario: 
(list test scenarios required to 1 . 

test change prior to user 
acceptance, this can be updated 
after the detailed design is 
complemented.) REQUIRED 
[Tester should prepare 
checklist based on these test 
scenarios for documentation 
on results of tests. These 
should be in matrix from 
identified back to the 
numbering scheme use in 
these test scenarios] 

16. Implementation: 

(Identify if there is an special 1 . The M7P established for this process must be followed for a 
implementation issues that planned or demand pit to be tracked on the Pitlog Reports. 

need to be addressed, i.e., field 
deployment, etc.) 

17. Attachments: 

(copies of screens, reports, etc. 
before and after proposed 
change) 
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1 . Fig. 29 is an exemplary table for Open Pitlog Report 

2. Fig. 30 is an exemplary table for Pending Open Request Report 

3. Fig. 3 1 is an exemplary table for Pending Close Request Report . 

4. Fig. 32 is an exemplary table for Open Pit Request 



5. Fig. 33 is another exemplary table for Open Pit Request 

6. Fig. 34 is an exemplary table for Close Pit Request 

7. Fig. 35 is another exemplary table for Close Pit Request 

Signatures of Agreement: 

(add additional rows if necessary) 
BAE: 

Lead Analyst: 



BAE Functional Requirement Document 



Table # 2042 



BAE Start Date: 05/22/1 996 BAE Name: Gail Deaton 
BAE Comp. Date: 05/28/1996 BAE Tele. No.: 977-3615 
BAE Hours: 20 



CMVC Component Name EXCEPTION GEOGRAPHIC LOCATION EDIT FOR 

DIGITAL LOOP ELECTRONICS 

Associated Defect/Feature 2042 
No.: 



Target Release: Target Release Date: 

(give target release this needs to be in) 2.0 (give target release date for this 04/02/1997 

enhancement) 



Priority: 

(provide priority from 'feature priority' list - production_hi 
productionjii through deferred_Jow 



Revision No.: 



Exh.2-Page351 



Reason for Revision: 



Subject: 

(brief description of change) 



Add edit into OSPCM Job Entry EWO to ensure that a ExGLC 
is present and is valid for digital loop electronics (DLE). 



Introduction: 

(description of what system currently 
does, what needs to be changed, and 
why) 



OSPCM currently does not require the entry of a ExGLC for 
digital loop electronics. The addition of this edit will answer a 
Internal Audit finding for the equipment placement in Network. 
The failure of ordering equipment to a ExGL results in 
accounting posting error. The equipment cannot be booked. 
A edit needs to be incorporated for placing DLE materials to 
ensure that a ExGL is entered by the user and that the ExGL is 
valid in CORTS. 



Solution: 

(describe what the system will or 
should do) 



The area_req_ind field is already in the ref edit application and 
Informix database and can be used for this feature. If this field 
is set to Y, an exception GLC is required. The field is in the frc 
table and the frc history table. The frc area_req_ind fields are 
downloaded as a local table so the field can be used for local 
VB edits. 



Change(s): 

(detailed description of change) - [add 
additional rows if multiple changes] 



The area_req_ind field is already in the ref edit application and 
Informix database and can be used for this feature. If this field 
is set to Y, an exception GLC is required. The field is in the frc 
table and the frc history table. The frc and area_req_ind fields 
are downloaded as a local table so the field can be used for 
local VB edits. 



Job entry VB presentation would add several new error 
messages. Two new Job Entry/Configuration "C functions 
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required to respond to the "Save" function of the VB 
presentation: 

1) Examine the substep FRC and determine if the FRC 
requires an Exception GLC. 

2) Validate the Exception GLC associated with the DLE 
substeps to ensure: 

a) it is a valid GLC 

b) the exception GLC does not belong to a wire center 

c) the exemption GLC does not belong to an inventory site 

OPEDS Pricing Contract "C" code required to call the above 
two new functions to edit substep information coming from 
OPEDS. 

CHANGES TO GUI : 

Better correlation between the Materials screens and the 
substep screens would be necessary. No new fields would be 
necessary on the Job Entry EWO screens but exception GLC is 
not on the same screen with the substep information. Exception 
GLC should be validated as mentioned above. Therefore, when 
an exception GLC is required, the user should be forced to go to 
the Materials screens and enter the GLC. 

NEW MESSAGES : 

1 . "The FRC associated with this substep requires an 
Exception GLC" 

2. "Exception GLC is not a valid GLC." 

3. "Exception GLC is currently associated with an 
existing Wire Center." 

4. "Exception GLC is currently associated with an 
existing Inventory Site." 

NEW/CHANGED CONTRACTS FOR CDF FILE : 
Contracts to examine the FRC of the substep and determine if 
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the FRC requires an Exception GLC. Contract to validate GLC 
to see if already associated with a wire center or an inventory 
site. 



Performance Requirements: 

(list any performance requirements 
associated with this change) 



Dependencies: 

(list any defects or features that this 
enhancement is dependent on) 



Benefits: 

(Provide benefits in dollars, reduced Answers Internal Audit finding against DLC equipment 
headcount, time saving, etc, for doing placement in Network 
this work) 

(Check) (Check) 

8. Affected Components: 

Yes No 



RTOC Instructions 

HELP x 

User Guides x 

Testing x 

Infra-structure 

Management Reports 

Database x 



(Check) (Check) 
Work-around: Yes No 

(is there a temporary work . x 

around?) 

(describe work around in 
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detail) 



Risks: 

(list factors that impact, Not responding to audit finding 

positive/negative, not doing 
this change) 

Business Rules: 

(list any business rules that 
should apply) 

Documentation Changes: 

(list affected documents 1 A 

requiring change) 

Test Scenario: 

(list test scenarios required to 
test change) 

Attachments: 

(copies of screens, reports, etc. 8. 
before and after proposed 
change) 

Signatures of Agreement: 

(add additional rows if necessary) 
BAE: 

Lead Analyst: 
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BAE Functional Requirement Document 



Table #1263 



BAE Start Date: 04/03/1996 BAE Name: Gail Deaton 

BAE Comp. Date: 04/05/1996 BAE Tele. No.: 977-3615 
BAE Hours: 6 

CMVC Component Name CORE TABLES - CONFIGURATION 

Associated Defect/Feature 2042 
No.: 

Target Release: Target Release Date: 

(give target release this needs to be in) 2.01 (give target release date for this 06/30/1997 

enhancement) 

Priority: 

(provide priority from 'feature priority' list - production Jii 
production hi through deferred_low 

Revision No.: 
Reason for Revision: 



Subject: 

(brief description of change) Add drop down boxes on the Configuration Tables. 
Introduction: 

(description of what system currently The Configuration Editor Module is a district user tool. In 

does, what needs to be changed, and adding information to the Resource Group/Work Type screen 
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why) 



the user should have drop down selections. 



Solution: 

(describe what the system will or Configuration Editor Module -On the Resource Group/Work 

should do) Type screen, drop down selection boxes should be available in 

two fields. 

• The "Schedule Sequence Code" field is edited against the 
sched_sequence table. A drop down selection box should 
be available to the user. Entries in the drop down selection 
should be retrieved from the schedsequence table, the 
sched_seq_cd field. 

• The "Contract Type" field is edited against the 
contract type table. A drop down selection box should be 
available to the user. Entries in the drop down selection 
should be retrieved from the contract_type table, the 
contract type field. 

Change(s): 

See above. 

Performance Requirements: 

(list any performance requirements 
associated with this change) 

Dependencies: 

(list any defects or features that this 
enhancement is dependent on) 

Benefits: 

(Provide benefits in dollars, reduced Ease of use for the user. Faster selection time, 
headcount, time saving, etc, for doing 
this work) 

8. Affected Components: (Check) (Check) 
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Yes 



No 



RTOC Instructions 

HELP x 

User Guides x 

Testing x 

Infra-structure 

Management Reports 

Database 

(Check) (Check) 
Work-around: Yes No 

(is there a temporary work 
around?) 

(describe work around in 
detail) 



Risks: 

(list factors that impact, These tables are not in a presentation that the user is privy to. There 

positive/negative, not doing no drop downs to indicate what a valid entry should be. The 

this change) configuration tables will be a source of user frustration. 

Business Rules: 

, (list any business rules that 
should apply) 



Documentation Changes: 

(list affected documents 
requiring change) 

Test Scenario: 

(list test scenarios required to 
test change) 
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Attachments: 

(copies of screens, reports, etc. 
before and after proposed 
change) 

Signatures of Agreement: 

(add additional rows if necessary) 
BAE: 

Lead Analyst: 



BAE Functional Requirement Document 



Table #1415 

BAE Start Date: 05/1 5/1 997 BAE Name: Gail Deaton 
BAE Comp. Date: 05/15/1997 BAE Tele. No.: 977-3615 
BAE Hours: 1 

CMVC Component Name CORE TABLES - CONFIGURATION 

Associated Defect/Feature 
No.: 

Target Release: Target Release Date: 

(give target release this needs to phase_3 .0 (give target release date for this 
be in) enhancement) 

Priority: 

(provide priority from 'feature priority' list - deferred Jii 
production_hi through deferredjow 

Revision No.: 
Reason for Revision: 

Subject: 

(brief description of change) 1 . If a job contains no prints and steps, disable the 

configuration button. 



Introduction: 
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(description of what system currently 1 . On the job outline screen the configuration button is 
does, what needs to be changed, and enabled before any prints and steps are entered. If the 

why) user clicks on the configuration button, OSPCM tries to 

configure the job. Configuration is kicked off and a 
message is sent to user. After processing, a successful 
configuration message is sent to the user. 



Solution: 

(describe what the system will or 1 . Do not allow configuration to be kicked off when the 

should do) job is empty. 



Change(s): 

1 . Disable the configuration button until a print, step, 
substep has been successfully saved. 



Performance Requirements: 

(list any performance requirements 1 . 

associated with this change) 



Performance should not be impacted. 



Dependencies: 

(list any defects or features that this 
enhancement is dependent on) 



Benefits: 

(Provide benefits in dollars, reduced 
headcount, time saving, etc, for doing 
this work) 



1 . Save processing time. 

2. Enhance user acceptance. 



Affected Components: 



(Check) 
Yes 



(Check) 
No 
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RTOC Instructions 
HELP 

User Guides x 
Testing x 
Infra-structure 
Management Reports 
Database 



Interfaces 

(list any legacy or new interface systems 1 . 
impacted by this change) 



(Check) (Check) 
Work-around: Yes No 

(is there a temporary work X 
around?) 

(describe work around in 1 . 

detail) 



Risks: 

(list factors that impact, 
positive/negative, not doing 
this change) 



1 . Confusion of the user 

2. Save processing time 



Business Rules: 

(list any business rules that 1 . Do not allow the configuration process to be kicked off until at 
should apply) least one print, step, substep has been saved. 



Documentation Changes: 

(list affected documents 1 . 

requiring change) 



Acceptance Criteria/Test Scenario: 

(list test scenarios required to 1 . Enter a new job on the job entry information screen. Save and 
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test changes) close. The job outline will appear. Verify that the 

configuration button is disabled. 
2. Enter a new job on the job entry information screen. Save and 
close. The job outline will appear. Verify that the 
configuration button is disabled. Enter a print, step, substep to 
the job. Save and close. On the job entry outline verify that the 
configuration button is enabled. Configure the job. Verify a 
successful configuration. 

Attachments: 

(copies of screens, reports, etc. 
before and after proposed 
change) 

Signatures of Agreement: 

(add additional rows if necessary) 
BAE: 

Lead Analyst: 
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BAE Functional Requirement Document 



Table #1416 



BAE Start Date: 05/15/1997 BAE Name: Gail Deaton 
BAE Comp. Date: 05/15/1997 BAE Tele. No.: 977-3615 
BAE Hours: 1 



Target Release Date: 

(give target release date for this 
enhancement) 

deferred_hi 



CMVC Component Name: Job Entry - EWO 

Associated Defect/Feature 
No.: 

Target Release: 

(give target release this needs to phase_3.0 
be in) 

Priority: 

(provide priority from 'feature priority' list - 
production hi through deferredjow 

Revision No.: 
Reason for Revision: 

Subject: 

(brief description of change) 1 . 

2. 



PWO type jobs should not allow billing codes or 
replaced items. 

Add a edits to ensure that that Job Name starts will 
PWO. 
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Introduction: 

(description of what system currently 
does, what needs to be changed, and 
why) 



Currently billing information can be added to a PWO. 
This is not allowable under BellSouth policy. 
The Job Name for a PWO type job will currently accept 
any format. This is unacceptable in that a PWO job 
type must always start with PWO. 



Solution: 

(describe what the system will or 
should do) 



1. 



2. 



Add edits to the PWO job to disallow any billing 
information entries. 

Ensure that a PWO job name start with 'TWO...' 



Change(s): 

(detailed description of change) - [add 
additional rows if multiple changes] 



1 . Gray out fields that are for billing information on a 
PWO. 

• On the Job Information screen, gray out 
"CLAIM#" 

• On the Placing screen, gray out the "Billing" 

field 

• On the Placing screen, gray out the "Replaced 
Item" icon 

• On the Splicing screen, gray out the "Billing' 

field 

• On the Splicing screen, gray out the "Replaced 
Item" icon. 

2. On the Job Information screen, prepopulate "PWO. . ." 
in the Job Name field. 



Performance Requirements: 

(list any performance requirements 
associated with this change) 



1 . Performance should not be affected 
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Dependencies: 

(list any defects or features that this 1 . 
enhancement is dependent on) 

Benefits: 

(Provide benefits in dollars, reduced 1 . 
headcount, time saving, etc, for doing 
this work) 



Affected Components: (Check) (Check) 

Yes No 

RTOC Instructions 

HELP x 

User Guides x 

Testing x 

Infra-structure 

Management Reports 

Database 



Interfaces 

(list any legacy or new interface systems 1 . 
impacted by this change) 



Work-around: 

(is there a temporary work 
around?) 

(describe work around in 
detail) 

Risks: 

(list factors that impact, 
positive/negative, not doing 
this change) 



(Check) 
Yes 



1. 



(Check) 
No 



X 



1 . This feature will ensure the user does not enter erroneous 
information on a PWO type job. 
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Business Rules: 

(list any business rules that 1 . 
should apply) 2. 

Documentation Changes: 

(list affected documents 1 . 

requiring change) 

Acceptance Criteria/Test Scenario: 

(list test scenarios required to 1 . 
test changes) 



2. 



3. 



Billing information cannot be entered on a PWO type job. 
the Job Name for a PWO type job must begin with "PWO. 



Enter information for a new PWO. 

• On the Job Information screen, verify that "CLAIM" is 
grayed out 

• On the Placing screen verify that the "Billing" field is 
grayed out 

• On the Placing screen, verify that the "Replaced Item" icon 
field is grayed out 

• On the Splicing screen, verify that the "Billing" field 
grayed out 

• On the Splicing screen, verify that the "Replaced Item" 
icon grayed out 

On the Job Information screen, verify that "PWO..." is 
prepopulated in the Job Name field. 

Enter substep information for placing and splicing. Save and 



Configure. Verify a successful configuration. 



Attachments: 

(copies of screens, reports, etc. 1 . 
before and after proposed 
change) 

Signatures of Agreement: 

(add additional rows if necessary) 
BAE: 

Lead Analyst: 
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BAE Functional Requirement Document 

Table # 2035 

BAE Start Date: 1 1/20/1996 BAE Name: Gail Deaton 
BAE Comp. Date: 1 1/21/1996 BAE Tele. No.: 977-3615 
BAE Hours: 4 

CMVC Component Name: Reorg 

Associated Defect/Feature 2035 
No.: 

Target Release : Target Release Dat e : 

(give target release this needs to 2.01 (give target release date for this 06/30/1996 

be in) enhancement) 

Priority: 

(provide priority from 'feature priority' list - production hi 
productionjii through deferred_low 

Revision No.: 
Reason for Revision: 

Subject: 

(brief description of change) Add OPF parameter to determine on a CMC level if material 

will be furnished by Telco, the Master Contractor, or a Vendor. 

Introduction: 
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(description of what system currently OSPCM currently assumes that the master contractor furnishes 
does, what needs to be changed, and all poles, manholes and conduit. A OPF parameter needs to be 
why) established to determine at a CMC level, which party will 

furnish material. This OPF will also establish the ability to 

handle Vendor provided material. 



Solution: 

(describe what the system will or Add OPF parameter to allow the input of the preference of 

should do) Telco furnished material, Master Contractor, or Vendor 

furnished material. 



Change(s): 

(detailed description of change) - [add CORE TABLES OPF 

additional rows if multiple changes] Add a OPF parameter that can be tied to a specific material 

category and subcategory. This parameter would have three 
options: 

• Telco Furnished 

• Master Contractor Furnished 

• Vendor Furnished 
JOB ENTRY -EWO 

• Material Status Flag 

1 . Telco furnished material will have the 
material status flag set to "N". 

2. Master Contractor furnished material will 
have the material status flag set to "U". 

3. Vendor furnished material will have the 
material status flag set to "U". 



PRICING 

• Price of materials 

1 . Telco furnished material - Dollars will be 
generated from the average disbursed price 
of the material item. 
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2. Master Contractor furnished material - 
Dollars will be generated from the material 
CWI code and it's associated price located 
in the specific master contract for the wire 
center. 

3 . Vendor furnished material - Dollar for 
vendor supplied material will be generated 
from the avg_price_amt populated in CID. 



Performance Requirements: 

(list any performance requirements 
associated with this change) 

Dependencies: 

(list any defects or features that this 
enhancement is dependent on) 

Benefits: 

(Provide benefits in dollars, reduced Accuracy in the ordering of materials needed for engineering 
headcount, time saving, etc, for doing work orders. Accurate price amount for the material. The 
this work) materials will be inventoried if required and disbursed from 

inventory when completed. 

Affected Components: (Check) (Check) 

Yes No 



Exh. 2 - Page 370 



RTOC Instructions 

HELP x 

User Guides x 

Testing x 

Infra-structure 

Management Reports 

Database x 



(Check) (Check) 
Work-around: Yes No 

(is there a temporary work X 
around?) 

(describe work around in 
detail) 



Risks: 

(list factors that impact, Poles, conduit and manholes are currently hard coded to be furnished by 

positive/negative, not doing the Master Contractor. There are some districts where Telco does order 
this change) and place into inventor poles, manholes and conduit. In these particular 

districts, OSPCM does not generate a material order and this is a 

manual process. 

Vendor supplied materials for DLE equipment are becoming more 
common place. This will allow the district to specify which material 
items will be supplied by the vendor. 

Pricing will not reflect the most accurate cost based on who supplies the 
material. 



Business Rules: 

(list any business rules that 
should apply) 



Documentation Changes: 
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(list affected documents 
requiring change) 

Test Scenario: 

(list test scenarios required to 
test change) REQUIRED 

Attachments: 

(copies of screens, reports, etc. 
before and after proposed 
change) 

Signatures of Agreement: 

(add additional rows if necessary) 
BAE: 

Lead Analyst: 

BAE Functional Requirement Document 

Table # 3640 

BAE Start Date: December 4, 1996 BAE Name: Carol A. Brechtel 

BAE Comp. Date: December 12, 1996 BAE Tele. No.: 205-977-361 1 

BAE Hours: 18 

CMVC Component Name: Job Entry - Reorg 

Associated Defect/Feature 3640 
No.: 

Target Release: Target Release Date: 
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(give target release this needs to 
be in) 



2.01 



(give target release date for this 
enhancement) 



July 1, 1997 



Priority: 

(provide priority from 'feature priority' list - production_hi 
production_hi through deferred_low 

Revision No.: 
Reason for Revision: 

Subject: 

(brief description of change) Functionality to rename a wire center, move a wire 

center/inventory site between CMCs, possibility in different 
states. The functionality to change resource id's assigned to the 
jobs that are involved in the reorg. 



Introduction: 

(description of what system currently 
does, what needs to be changed, and 
why) 



The system does not handle the moving or renaming of wire 
centers and/or inventory sites. Also can not update the resource 
id assigned to a job. 

Enhance the system to handle wire center name changes, 
movement of wire centers/inventory sites between CMCs, and 
to handle changing the resource id's assigned to do work on a 
job. 



Solution: 

(describe what the system will or 
should do) 



New user screens to handle the renaming of wire centers, the 
movement of inventory sites and wire center between CMCs, 
and the changing of resource ids. 

Crystal Report to printout the requested reorg information 
(possibility exist of handling more than one reorg request at a 
time). 

Management Reports to list all jobs involved in the reorg and 
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Change(s): 

(detailed description of change) - [add 
additional rows if multiple changes] 



one that will list all inventory (serialized and non-serialized) 
that should be moved in the reorg. These reports could be run 
before the reorg and again after the reorg to ensure that all data 
was moved properly. 

Batch runs that will actually move/update the data in the data 
bases. 

Types of reorgs/changes: 

1 . CMC consolidation 

2. Wire Centers and inventory sites split between two or 
more CMCs 

3. Resource ID changed in associated with wire center 
move 

4. Wire Center Name Change 

If the reorg involves adding a new CMC all navigator contracts 
must be updated with the new location. Also before the reorg is 
processed the location table must be updated with the new 
location. 

All data will be moved with the reorg batch process, this 
includes closed and completed job data. 

The following OSPCM executable will probably be affected by 
the reorg: 

Billing & Reporting, Complaints, Employee Editor, 
Inspections, Job Entry EWO, Job Entry Other, Location Editor, 
OPF Editor, Pricing, Scheduling and Work Station. 

Wire Center Name Change (Reorg Type #4): 

On a wire center name change OSPCM would need to update 
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all occurrences of the existing wire center name with the new 
wire center name. Before this type of change can be processed 
it will be necessary to build all the new wire centers in the 
location editor. 

CMC Consolidation, Wire C nt rs splits and R source ID 
changes (R org Types #1, #2 & #3): 

OSPCM would need to update all occurrences of the old CMC 
with the new CMC, when inventory sites and wire centers are 
moved. 

If CMC consolidation or split is being processed the reog would 
also need to update all the substeps assigned to the resource id 
to the new resource id. The user would provide the information 
for these changes by populating the Resource Id window. 

Job Entry - if all wire centers on a job are being moved to the 
same CMC the process should change the primary CMC to the 
new CMC, at the job header level. If the wire centers on a job 
are being split between two or more CMCs - the primary CMC 
should be changed to the CMC of the primary wire center 
shown on the job header. 

Pricing - The CMC is used when printing reports. The CMC 
should be updated in pricing identical to the change made in job 
entry. 

Configuration Table - If a CMC consolidation is being down 
update the tables with the new CMC. If wire centers from one 
CMC are being moved to multiple existing CMC no change is 
required. If wire centers are being moved from one CMC to 
multiple CMC, one of which is a new CMC, duplicate the table 
for the new CMC using the old CMC data. 
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Employee Table - If the old CMC is being deleted and all 
existing wire centers under that CMC are being moved to the 
same CMC the process should update the CMC on the 
employee table. 

If the wire centers are being split between multiple CMC the 
process should use the information on the resource id window 
to update the CMC and resource id on the employee table. 
Both Management and non-management employees need to be 
updated. 

The batch process should end date the existing employee record 
(from CMC and Res ID), and build a new employee record with 
the to CMC and Res ID. 

Workstation - all jobs should be moved to the new CMC, 
using the same procedures as indicated for job entry. 

Inspections - CMC information is stored on the inspection 
tables, when the reorg process is run it will be necessary to 
update the table with the to CMC. If wire centers are being 
split between multiple CMC, the process will need to read the 
wire center to determine which CMC to use. 

Location Editor - Move inventory site and wire centers tot he 
new CMC, and end date or delete the old CMC. If all data is 
being moved to the new CMC I don't see any reason to keep 
from CMC. 

If inventory is being moved from one inventory site to a new or 
exiting inventory site when the process is completed and all 
inventory has been moved. 
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Billing & Reporting - All jobs open and closed should be 
moved. This included all job types: BSW, EWO and RW. 

Job Entry Other - All jobs open and closed should be moved. 
This included all job types: BSW, EWO and RW. 

Scheduling - Scheduling read the job entry tables, so when 
they are updated by the reorg process and when the schedule is 
run it should pick up the correct data. 

Materials Management - Transaction should be generated 
whenever inventory is moved during the reorg process. A new 
transaction type will be needed. 

If a inventory site is being moved to a new or existing CMC, 
the inventory site name is not being changed, the process needs 
to change the CMC name associated with the inventory site. 
The inventory, serialized and non-serialized, would stay with 
the inventory site. 

All material request, material request item, serialized and non- 
serialized should be changed during the batch process. 

Completed orders should be moved during the process, since 
we are moving all job data, regardless of the status. 

If the reorg is attempting to move inventory at one site to 
multiple inventory sites the user will need to manually move 
the inventory )serialized and non-serialized) using the transfer 
process. The batch process would have no way of know what 
material to move where. 
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Performance Requirements: 

(list any performance requirements All updates must be made over the week-end. Reorg could 
associated with this change) begin on Friday night completing on Sunday so the users could 

verify that all data was updated correctly. System must be 
available on Monday morning, normal working hours. 



Dependencies: 

(list any defects or features that this None 
enhancement is dependent on) 



Benefits: 

(Provide benefits in dollars, reduced Keep wire center names current and accurate. Keep the system 
headcount, time saving, etc, for doing in line with realignment of districts, manager etc. 
this work) 

Affected Components: (Check) (Check) 

Yes No 



RTOC Instructions x 

HELP x 

User Guides x 

Testing x 

Infra-structure x 

Management Reports x 

Database x 



Interfaces: 

(list any legacy or new 
interface systems by this 
change) 

Majority of systems that interface with OSPCM would 
need to know about the changes we were making. In 
today's environment this is done be letters to MTR, 
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STAR, Financial Processing, BCAS, Asset 
Management etc. Any change moving or renaming 
wire centers in OSPCM would need to be coordinated 
with OPEDS. 

For a Wire Center name change OSPCM would need 
to coordinate the change with LMOS. 



(Check) (Check) 
Work-around: Yes No 

(is there a temporary work X 
around?) 

(describe work around in 
detail) 



Risks: 

(list factors that impact, Don't rename the wire center when area code splits are done, don't 

positive/negative, not doing move wire centers and inventory sites when CMCs are combined or 
this change) split. Management would be difficult since it would be almost 

impossible to pull data on the location you are responsible for. The user 
would also be required to manually update the resource id assigned to 
work a substep when changes are made. 



Business Rules: 

(list any business rules that 
should apply) 



1 . All jobs should be moved, closed, completed, open, canceled, 
etc. 

2. Management Report will not be involved in the reorg process. 

3 . The reorg should not generate duplicate job numbers. 

4. System should be backup before the reorg is run. 

5. Bid & Award, Regional Contract, BSW LookUp and the 
Holiday Editor do not need to updated with the reorg process. 

THIS IS JUST A START AT LISTING BUSINESS RULES AS THE 
PROCESS IS DETAILED IT MAY BE NECESSARY TO ADD 
OTHERS. 
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Documentation Changes: 

(list affected documents 
requiring change) 



No documentation exist for this process. Would need to develop M&P, 
test scenarios and functional decomps. 



Acceptance Criteria/Test Scenario: 



(list test scenarios required to 
test changes prior to user 
acceptance) 



1 . Consolidate two existing CMC 

2. Split wire centers and inventory sites between two CMC one 
existing and one new CMC) 

3. Rename several wire centers 

4. Change resource id assigned to do work on jobs. 
DETAILED TEST SCENARIOS WILL BE FURNISHED AT A 
LATER DATE 



Attachments: 

(copies of screens, reports, etc. Screen Layouts (wire center name change, wire center and inventory 
before and after proposed site moves, and resource id changes) 

change) Manual Reorg Efforts 

Open Issues 

Signatures of Agreement: 

(add additional rows if necessary) 
BAE: 

Lead Analyst: 
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BAE Functional Requirement Document 



Table # 2355 



BAE Start Date: 06/1 3/1 996 BAE Name: Gail Deaton 

BAE Comp. Date: 06/13/1996 BAE Tele. No.: 205-977-3615 

BAE Hours: 5 



CMVC Component Name: Job Entry - EWO ability to print OSPCM messages 

Associated Defect/Feature 2355 
No.: 



Target Release: Target Release Date: 

(give target release this needs to 2.0 (give target release date for this 04/02/1 997 

be in) enhancement) 



Priority: 

(provide priority from 'feature priority' list - production hi 
production ^ through deferred jow OSPCM plan B 



Revision No.: 
Reason for Revision: 



Subject: 

(brief description of change) Job Entry - EWO module - give the user the ability to print 

OSPCM generate messages. 



Introduction: 

(description of what system currently Currently Job Entry will generate messages for the user. Some 
does, what needs to be changed, and of these messages are lengthy. There is no print capability for 
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why) 



the message. The use must remember the message or write 
down the message. 



Solution: 



(describe what the system will or 
should do) 



Give the user print capability for OSPCM generated messages 
in Job Entry - EWO. 



Change(s): 

(detailed description of change) - [add OSPCM should provide print functionality for model error 



Performance Requirements: 

(list any performance requirements 
associated with this change) 

Dependencies: 

(list any defects or features that this 
enhancement is dependent on) 

Benefits: 

(Provide benefits in dollars, reduced Ease of use: more rapid error resolution. 

headcount, time saving, etc, for doing Save processing time - the user is forced to recreate the error 

this work) message if they do not remember the original message. 

Affected Components: (Check) (Check) 



additional rows if multiple changes] 



screens. This functionality should be added in 3 places: the 
substep save error screen, the delete warning and error 
messages, and the configuration error messages. 



Yes 



No 



Exh.2-Page382 



RTOC Instructions 



HELP 



x 



User Guides 



Testing 



x 



Infra-structure 



Management Reports 



Database 



(Check) 



(Check) 



Work-around: 



Yes 



No 



(is there a temporary work 
around?) 

(describe work around in 
detail) 

Risks: 

(list factors that impact, User acceptability of product will be at risk if this is not implemented, 

positive/negative, not doing 
this change) 

Business Rules: 

(list any business rules that 
should apply) 

Documentation Changes: 

(list affected documents 
requiring change) 

Test Scenario: 

(list test scenarios required to 
test change) 

Attachments: 
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(copies of screens, reports, etc. 
before and after proposed 
change) 

Signatures of Agreement: 

(add additional rows if necessary) 
BAE: 

Lead Analyst: 



BAE Functional Requirement Document 



Table # 3794 

BAE Start Date: 12/01/1996 BAE Name: Larry Rice 

BAE Comp. Date: 12/02/1996 BAE Tele. No.: 977-7436 

BAE Hours: 3.0 

CMVC Component Name: bill report 



Associated Defect/Feature 
No.: 

Target Release: 

(give target release this needs to 2.0 
be in) 

Priority: 

(provide priority from 'feature priority' list - 
productionhi through deferred_low 

Revision No.: 
Reason for Revision: 



Target Release Date: 

(give target release date for this Pilot 
enhancement) 

prod_hi 



Subject: 

(brief description of change) Make the necessary software changes to facilitate the invoicing 

changes required for the Supplier Transactions and Remittace 
(STAR) system. 



Introduction: 

(description of what system currently What system currently does: Today OSPCM provides a 
does, what needs to be changed, and mechanized feed to SAVE/MAPS that bundles the contractor 
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why) completions to invoices and then create a voucher. The 

voucher number is generated by OSPCM and is printed on the 
pay draft generated by SAVE/MAPS. This voucher number 
enables the contractor to identify step & substep completions in 
OSPCM that have been bundled on an invoice and voucher. 
The SAVE/MAPS system will be replaced by the Supplier 
Transactions and Remittance (STAR) system effective January 
1, 1997. STAR does not use OSPCM generated vouchers but 
instead is a one-to-one OSPCM invoice to a STAR voucher. 

What needs to be changed: Billing & Reporting needs to 
revise all VB presentations and Crystal reports that use the 
Voucher as a key to determine payment for the contractor. The 
contractors will use only the Invoice Number when navigating 
the B&R screens when query about payments. All functionality 
that dealt with Vouchers will be focused on an Invoice, with all 
references to Vouchers eliminated. 



Why system needs to be changed: STAR draft payments will 
be populated with the OSPCM Invoice Number not the STAR 
voucher number. The Invoice Number will be the key which 
the contractor will use to query OSPCM to determine what 
completions have been bundled on an invoice. 



Solution: 

(describe what the system will or The Billing & Reporting VB presentation for Vouchers will 

should do) need to be modified to present only the Invoices. All references 

to Vouchers for VB GUI and Crystal reports will be changed to 
focus on the Invoice Number. The logic to display the 
currently 90 day billing should stay the same. The server 
process that bundles completions to an invoice should always 
try to maximize the STAR limit of 250 detail lines on an 
invoice. 



Exh.2-Page386 



Change(s): 

(detailed description of change) - [add 
additional rows if multiple changes] 



Modify Mail Menu selection from Vouchers to Invoices. 
Remove Voucher control from Identify the Invoice frame. 
Group the State, CMC & Contract # controls within the 
Identify the Invoice frame. 

Remove Vouchers grid from Identify the Invoice frame. 
Relocate Invoice grid to be centered on the Identify the 
Invoice frame. 

Add Job Number text box to the Identify the Invoice 

frame. 

Expand Invoices grid size to display more invoice detail 
lines on the Invoice Number screen. 
Add Job Number grid to frame to display invoice detail 
lines on the Job Number screen. 

Remove all references to Voucher from all frames, screens 
and Crystal reports. 



Performance Requirements: 

(list any performance requirements Ensure that the 90 day time period does not impact on response 
associated with this change) time to populate this grid. May need to re-evaluate the time 

frame and consider 60 days if performance becomes and issue. 



Dependencies: 

(list any defects or features that this The removal of the Voucher grid is dependent on the success of 
enhancement is dependent on) the Phase I changes made for the initial OSPCM/STAR source 

feed changes effective 01/01/97. With the existing 
SAVE/MAPS voucher still in the 90 day window through the 
end of March, the contractor will still need the ability to relate 
OSPCM generated Voucher Number to Invoice Number for a 
period of time after the initial implementation. This will 
probably me a mote point with the scheduled field trail date of 
May 1007. This will be well past the 90 day window at the 
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time OSPCM Phase II goes to field trail. 



Benefits: 

(Provide benefits in dollars, reduced 
headcount, time saving, etc, for doing 
this work) 



• No headcount reduction 

• No benefit in dollar savings 

• Required functional changes imposed by the Phoenix 
project. 



Affected Components: 



(Check) 
Yes 



(Check) 
No 



RTOC Instructions 
HELP 
User Guides 
Testing 

Infra-structure 
Management Reports 
Database 



x 
x 
x 



x 

X 
X 



Work-around: 

(is there a temporary work 
around?) 

(describe work around in 
detail) 



(Check) 
Yes 



(Check) 
No 



X 



Risks: 

(list factors that impact, 
positive/negative, not doing 
this change) 



The contractor will have no way of matching his draft payment 
information with OSPCM data unless the Invoice Number is used as the 
key for payment queries. The OSPCM generated Voucher Number will 
have no meaning with the implementation of STAR. 



Business Rules: 



Exh. 2 -Page 388 



(list any business rules that 
should apply) 



The server process should maximize the STAR limit of 250 invoice 
detail lines on an invoice. The reduction of the number of invoices 
generated by this bundling process will make the process much simpler 
for the contractor to determine what completions are bundled on an 
invoice for payment. 



Documentation Changes: 

(list affected documents 
requiring change) 



HELP 
User Guide 
Instructor Guide 
Functional Decomp 
Test plan 



Test Scenario: 

(list test scenarios required to 
test change) 



Attachments: 

(copies of screens, reports, etc. 
before and after proposed 
change) 

Signatures of Agreement: 

(add additional rows if necessary) 
BAE: 

Lead Analyst: 
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BAE Functional Requirement Document 



Table # 6254 



BAE Start Date: 04/30/97 BAE Name: Larry Rice 

BAE Comp. Date: 05/01/97 BAE Tele. No.: 977-7436 

BAE Hours: 2.0 Hours 



CMVC Component Name: bill_report 

Associated Defect/Feature 6254 
No.: 



Target Release: 

(give target release this needs to 2.0 1 
be in) 



Target Release Date: 

(give target release date for this 06/01/97 
enhancement) 



Priority: 

(provide priority from 'feature priority' list - productionhi 
productionjii through deferred_low 



Revision No.: 
Reason for Revision: 



Subject: 

(brief description of change) 1 . In Phase 2.0 as well as in Phase 1.09, any time that 

Routine Work, EWO Exhibit 'B' or EWO Exhibit 
'B/A' work orders are requested to display, print or 
local, all steps are printed regardless whether they have 
open or closed substeps on a step. The application 
needs to be changed so that only those steps that 
have open substeps will display, print or local 
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download when request in New and Existing. 



1 . Currently when work orders for Routine Work, EWO 
Exhibit 'B' or EWO Exhibit 'B/A' are requested to 
display, print or local, all steps for the job request are 
displayed, printed or downloaded to the clients C drive, 
regardless of there status of 'OP' or 'CO'. 

2. The application needs to be changed so that only those 
work orders for Routine Work, EWO Exhibit 'B' or 
EWO Exhibit 'B/A' that have at least one open substep 
on a step display, print or local when requested from 
New or Existing by the contractor. 

3. When the contractor selects a RW or EWO job to 
display, print or local in New or Exiting, the search 
retrieves all job, prints, steps and substeps, regardless if 
they are 'OP' or 'CO'. If a job were to have (99) 
closed steps and (1) open step, the application will print 
all (100) steps. This would require the contractor to sift 
through these (100) work orders to find the (1) that still 
required work to be dispatched on. 



Introduction: 

(description of what system currently 
does, what needs to be changed, and 
why) 



Solution: 

(describe what the system will or 1 . For New and Existing, when the contractor requests 

should do and any general constraints work orders for Routine Work, EWO Exhibit 'B' or 

or conditions that limit the solution) EWO Exhibit 'B/A', only those work orders that have 

at least one open substep on a step should be retrieved 
and displayed, printed or downloaded to the clients C 
drive. 



Change(s): 

(detailed description of change) - [add 1 . 
additional rows if multiple changes] 



New Work Orders for RW, EWO Exhibit <B' & 
EWO Exhibit 'B/A' 
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• Retrieve and then display, print or local all job 
numbers that have at least one open substep on a 
step and have not been accepted by the contractor. 

• If there are multiple substeps on a step then display 
all substeps for each step that have at least one 
open substep on the step and display the status code 
for each substep. 

• If there are no open substeps on a step then do not 
display, print, local that step. 

• For each work order page break on each step 
number, sorted by Job, Print and Step Number. 

1 . Existing Work Orders for RW, EWO Exhibit 'B' & 
EWO Exhibit 'B/A' 

• Retrieve and then display, print or local all job 
numbers that have at least one open substep on a 
step. 

• If there are multiple substeps on a step then display 
all substeps for each step that have at least one 
open substep on the step and display the status code 
for each substep. 

• If there are no open substeps on a step then do not 
display, print, local that step. 

• For each work order page break on each step 
number, sorted by Job, Print and Step Number. 

Performance Requirements: 

(list any performance requirements 1 Changes should no impact on performance, 
associated with this change) 

Dependencies: 

(list any defects or features that this 1 None 
enhancement is dependent on) 
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Benefits: 

(Provide benefits in dollars, reduced 
headcount, time saving, etc, for doing 
this work) 



1 For the contractor, only those work orders that have 
work remaining to complete will display, print or local. 



Affected Components: 



(Check) 
Yes 



(Check) 
No 



Interfaces: 

(list any legacy or new 
interface systems impacted by 
this change) 



None 



RTOC Instructions 
HELP 
User Guides 
Testing 

Infra-structure 
Management Reports 
Database 



x 
x 



Work-around: 

(is there a temporary work 
around?) 

(describe work around in 
detail) 



(Check) 
Yes 



(Check) 



No 
X 



Risks: 

(list factors that impact, 
positive/negative, not doing 
this change) 



1 In the case of a job that has many steps that have bee completed 
and then a new step is added, the process will continue to print all of the 
open and closed steps. 
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Business Rules: 

(list any business rules that 1 See changes 
should apply) 



Documentation Changes: 

(list affected documents 1 User guide 

requiring change) 



test change prior to user 
acceptance) (REQUIRED) 



Acceptance Criteria/Test Scenario: 

(list test scenarios required to 1 . Select a RW and EWO that have both open and closed steps to 

validate that only those steps that have at least one open substep on 
them are printed, displayed or downloaded to the clients C drive in 
both New and Existing. 
2. Add new step in JEO to a RW and EWO that have no open steps to 
validate that when new work is added that only the new step that 
had been added is printed, displayed or downloaded to the clients C 
drive in both New and Existing. 



Attachments: 

(copies of screens, reports, etc. 1 
before and after proposed 
change) 

Signatures of Agreement: 

(add additional rows if necessary) 
BAE: 

Lead Analyst: 
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BAE Functional Requirement Document 



Table # F5305_fs.doc 

BAE Start Date: 12/02/1996 
BAE Comp. Date: 01/15/1997 
BAE Hours: 25 

CMVC Component Name: Bid & Award 

Associated Defect/Feature 5304 
No.: 

Target Release: 

(give target release this needs to 1 .9 (give target release date for this 

be in) enhancement) 

Priority: 

(provide priority from ' feature priority' list - HI 
production hi through deferred low 

Revision No.: 

Reason for Revision: To provide printing capabilities for existing contracts 

Subject: 

(brief description of change) Make system changes necessary to allow the user to print any 

existing contract when eve the need arises. 



BAE Name: Ron Cochran 
BAE Tele. No.: 205-977-7444 
LA Assigned: 



Introduction: 

(description of what system currently Currently, the contract coordinator can only print a copy of the 

does, what needs to be changed, and contract when the system is used for bidding purposes. At that 

why) time, the contract can be printed (including the appropriate 
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Solution: 

(describe what the system will or 
should do and any general constraints 
or conditions that limit the solution) 

Change(s): 

(detailed description of change) - [add 
additional rows if multiple changes] 



prices and other associated data substitution) only until the 
contract is in effect. At that time, the specific documents for 
that contract are stored on the local access data base. These 
documents should be placed on the server and then have the 
capability to print them upon demand. This is specifically 
needed when a contract work adjustment has been made. In 
addition , there are no provisions for entering or printing 
contact documents on conversion contracts which were not bid 
through OSPCM. 

The system should allow the user to select from the contract 
type's current regional/status documents for a conversion 
contract. It should be modified to allow the printing of a 
portion or all of the selected documents whenever necessary. 

1 . All access to these functions come from the OPEN 
Contracts screen. The present edits on that form should be 
continued. 

2. The Contract Maintenance from should have an additional 
icon added with the title of Print Doc Copy. An edit should 
be performed when the Print Doc Copy is selected. The 
edit should verify that the contract prices are activated and 
the start date of the contract is today or in the past. If not, 
the user should received an error which essentially states 
that they cannot print a contract which is not in effect. For 
individual contracts (future consideration) the start date is 
not applicable. 

3. When this action is complete, three tabs should be 
available: the Build, Edit and assemble tabs are used for 
input. These are identical in appearance and functionality 
as the Bid Package forms with the following limitations. 
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Assemble 



• If the contract is one which was bid using 
OSPCM, the Selected Components grid 
should be populated with the documents 
previously stored for the specific contract. 
These documents cannot be deselected. 

• The Available Components grid should be 
populated with regional and state document 
types which were not stored for the specific 
contract. These document types be may be 
selected or deselected in the Selected 
Component grid. The final selected 
components will be saved as specific 
documents for this particular contract upon 
SAVE or SAVE/CLOSE. 

• If the contract is a conversion contract, the 
Selected Components grid will be blank. 
The user may select any of the documents 
from Available Components grid. 

Edit 

• All documents (except articles) may be 
modified by the user regardless of whether 
the contract is a conversion or bid contract. 
The exact functionality as the Bid Package 
form should be carried forward to this 
form. 

Build 

• In all cases, the Bidders Grid should be 
populated with the contractor name for this 
specific contract. The grid should be a 
read only grid. 

• The Components Grid has the same 
functionality as it does when used as part 
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of the Bid Package. 
• The Print and Disk options will have the 
same functions with the following 
exception. The print to file will be for 
documents only. There is only one disk. 
No Excel spread sheets will be produced 
since no interaction with the contractor is 
necessary. 



Performance Requirements: 

(list any performance requirements None 
associated with this change) 



Dependencies: 

(list any defects or features that this None 
enhancement is dependent on) 



Benefits: 

(Provide benefits in dollars, reduced When the original specifications were written for this module, 
headcount, time saving, etc, for doing every contract coordinator had a clerical person assigned to 
this work) them. In addition, three other clerks at the core headquarters 

were available to help these people. By the end of the first 
quarter, there will be no clerical help for the coordinator. In 
addition, the Mechanized Analyze and Contract Payment 
Administration System (MACPAS) has been discontinued. 
That system would print new contracts when additional items 
were added or deleted or PIC adjustments are made. 

The additional functionality of printing these contract through 
OSPCM will save a minimum amount of 1200 hours per year 
for a PG58 Manager. 
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Affected Components: 

RTOC Instructions 
HELP 

User Guides 
Testing 
Infra-structure 
Management Reports 
Database 



(Check) 
Yes 



x 

X 
X 



(Check) 
No 

x 



x 
x 



Interfaces: 

(list any legacy or new None 
interface systems 
impacted by this 
change) 



Work-around: 

(is there a temporary work 
around?) 

(describe work around in 
detail) 



(Check) 
Yes 



(Check) 
No 

X 



Risks: 

(list factors that impact, 
positive/negative, not doing 
this change) 



Possibility of very negative adverse reaction on the part of the field 
users by not having a copy of the most up-to-date prices in a reasonable 
time frame. Other duties of the contract coordinator in a time of 
reduced personnel will be severely curtailed. 



Business Rules: 

(list any business rules that 
should apply) 



In change text. 
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Documentation Changes: 

(list affected documents 
requiring change) 



None (other than user guides) 



Acceptance Criteria/Test Scenario: 

(list test scenarios required to Functionality of forms 

test change prior to user 

acceptance) 

Attachments: 

(copies of screens, reports, etc. None 

before and after proposed 

change) 

Signatures of Agreement: 

(add additional rows if necessary) 
BAE: 

Lead Analyst: 
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BAE Functional Requirement Document 



Table # 6092 



BAE Start Date: 4/30/1 997 
BAE Comp. Date: 05/20/1 997 
BAE Hours: 7 



BAE Name: Gail W. Deaton 
BAE Tele. No.: 977-3615 
LA Assigned: 



CMVC Component Name: CONFIGURATION EDITOR 



Associated Defect/Feature 6901 
No.: 



Target Release: Target Release Date: 

(give target release this needs to phase_2. 1 (give target release date for this 09/0 1/1997 

be in) enhancement) 



Priority: 

(provide priority from 'feature priority' list - production-med 
productionjii through deferred_low 



Revision No.: 
Reason for Revision: 



Subject: 

(brief description of change) 1 Give the user global delete capability in Configuration 

Editor for a expired resource 
2 Give the user copy capability in Configuration Editor 
for a new resource. 
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Introduction: 

(description of what system currently 1 
does, what needs to be changed, and 
why) 

2 



Solution: 

(describe what the system will or 1 

should do and any general constraints 

or conditions that limit the solution) 2 

Change(s): 

(detailed description of change) - [add 1 . 
additional rows if multiple changes] 



Currently the system does not have global delete 
capability for a resource. This delete capability should 
be given to the user for expired resources. 
Currently the system does not have any copy capability. 
Give the user the ability to copy the work types for an 
newly created resource. 

If a RESID is expired, allow a global delete in 
Configuration Editor. 

Add the ability to copy work types from an existing 
resource for newly created RESIDs. 

Add a "Delete Resource" icon on the Resource 
Group/Work Type screen. When the icon is clicked, a 
screen should appear that states: "Enter RESID to be 

deleted. . This is a global delete. Save will 

remove this RESID from Resource Group/Work Type; 
Resource Group/Wire Center Area; and the Resource 
Group/Work Type/Wire Center. Only expired RESIDs 
will be globally deleted." Implement an edit to check 
the expiration date of the RESID. If the expiration is 
today or in the future, do not allow the delete and issue 
error message. EMU should read "This RESID is not 
expired. Cannot delete." 

Add a new screen to Configuration Editor. This should 
be a COPY RESOURCE screen. The user will enter 
the RESID and the Wire Center to be copied; and the 
RESID and the Wire Center to receive the copy. This 
copy should populate the data for the Resource 
Group/Work Type screen and the Resource 
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Group/Wire Center Area screen should be prepopulated 
by the user before trying to use the COPY RESOURCE 
screen. 

• Add an edit on the save for the COPY 
RESOURCE that the RESID to receive the copy 
must be in the Resource Group /Wire Center Area 
Table and must have Travel Time and Inventory 
Site populated. 

• Add an edit that the RESID to receive the copy 
must not be expired. 

• Allow the copies from RESID to be activate or 
expired . 



Performance Requirements: 

(list any performance requirements 
associated with this change) 



change. 



1 



Performance of OSPCM should not be affected by this 



Dependencies: 

(list any defects or features that this 
enhancement is dependent on) 



This Feature is dependent on Feature 6091 



Benefits: 



(Provide benefits in dollars, reduced 
headcount, time saving, etc, for doing 
this work) 



1 User input time will be greatly reduced by these global 
deletes and copies. 



Affected Components: 



(Check) 



(Check) 



Yes 



No 
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RTOC Instructions 

HELP x 

User Guides x 

Testing x 

Infra-structure 

Management Reports 

Database 



Interfaces: 

(list any legacy or new 1 
interface systems 
impacted by this 
change) 



Work-around: 

(is there a temporary work 
around?) 

(describe work around in 
detail) 



(Check) 
Yes 

X 



(Check) 
No 



1 User will individually delete or add work types to the 
Configuration Editor. 



Risks: 

(list factors that impact, 1 User acceptability of the OSPCM product, 

positive/negative, not doing 
this change) 



Business Rules: 

(list any business rules that 1 A RESID cannot be globally deleted from the Configuration 
should apply) Editor unless it is expired. 

Documentation Changes: 

(list affected documents 1 . 

requiring change) 
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K 



Acceptance Criteria/Test Scenario: 

(list test scenarios required to 1 . 
test change prior to user 
acceptance) REQUIRED 



Enter a RESID that is not expired using the DELETE 
RESOURCE icon on the Resource Group/Work Type screen. 
Should received EMU that the RESE) is not expired and cannot 



be deleted. 

2. Enter a RESE) that is expired using the DELETE RESOURCE 
icon on the Resource Group/Work Type screen. Delete the 
Resource. 

• Pull up the Resource Group/Work Type screen and search 
for work types linked to this RESID. None should be 
linked. 

• Pull up the Resource Group/Wire Center Area screen and 
search for linked wire centers. None should be linked. 

• Pull up the Resource Group/Work Type/Wire Center screen 
and search for linked work types. None should be linked. 

3 . On the COPY RESOURCE screen, enter information to copy a 
RESID. Verify via Management Reports that the data was 
correctly copies and applied to the correct wire center. 



Attachments: 



(copies of screens, reports, etc. 1 
before and after proposed 
change) 

Signatures of Agreement: 

(add additional rows if necessary) 



BAE: 



Lead Analyst: 
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BAE Functional Requirement Document 



Table #4665 



BAE Start Date: September 23, 1996 
BAE Comp. Date: November 05, 1996 



BAE Name: 



Gail Deaton 



BAE Tele. No.: 977-3615 



BAE Hours: 



28 



CMVC Component Name: 4665 



Associated Defect/Feature 



No.: 



Target Release: 

(give target release this needs to 2.0 
be in) 



Target Release Date: 

(give target release date for this 
enhancement) 



03/1997 



Priority: 

(provide priority from 'feature priority' list - productionhi 
productionjii through deferred_low 

Revision No.: 
Reason for Revision: 

Subject: 

(brief description of change) add features to handle DLC Turnkey applications 
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Introduction: 

(description of what system currently 
does, what needs to be changed, and 
why) 



The vendor is responsible for total project management of each 
application. The vendor sends a paper request to the BellSouth 
Purchasing Group to request BellSouth to order materials. This 
procedure takes the local district personnel out of the loop for 
equipment ordering/receipting material/and tracking inventory 
until the product is delivered fully assembled. 

OSPCM changes will allow for the encoding, prevention of 
ordering, and the disbursement of DLC turnkey substeps. 



Currently, OSPCM and OPEDS have no features for DLC 
turnkey applications. DLC turnkey is a process in which a 
vendor orders necessary equipment for a DLC, assembles the 
equipment, makes splices and performs pre-service turn up 
carrier systems. 



Solution: 

(describe what the system will or 
should do) 

For Job Entry the placing substeps, splicing substeps and the 
data base will need to be changed to allow the encoding of each 
piece of equipment, cable or splice with a DLC Turnkey 
indicator. 

The DLC turnkey indicator will turn off or blank out any STFs 
and CWI's generated by configuration. 



OSPCM will require changes in the Job Entry Module, the 
Materials Module, Management Reports and possibly the 
Scheduling Module. 
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OPEDS must incorporate the above changes in the substep data 
sent to OSPCM. ODEDS/OSPCM contracts must be revised to 
transmit the data. 

Materials will read the indicator and not calculate an order date 
and on job date if the indicator is set to "Y" but will leave the 
material in the "N" needed status. Once assembled, this 
material gets shipped to the field and must be added to 
inventory and assigned to a job. The material is added to 
inventory using the Inventory Add process and checking 
turnkey. The Needed and the All Requirements screens need to 
be changed to display the DLC turnkey indicator on each 
substep. If the substep is selected to be ordered, a new edit 
mush be added so that substep cannot be ordered. 

Scheduling will need to add another scheduling code of DLC- 
TNKY in order to place all the turnkey equipment and splicing 
into the same activity. Another labor type of "VS", vendor 
supplied will be required. 

Upon completion of a substep the Material Module will 
disburse the materials as required from inventory. 

Workstation and Contractor Reporting will disburse the items 
to CPR. 

A management report will also be required to list the material 
components of a DLC Turnkey. 
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Change(s): 

(detailed description of change) - [add Job Entry- Add DLC turnkey indicator on the Material Data 
additional rows if multiple changes] - Order Data screen. Options for this indicator will be "Y" or 

"N'\ The default for this indicator will be "N". A indicator 
must also be added for the splicing screen to indicate turnkey. 
Add DLC turnkey indicatory in the job entry data base. 

Materials- Add code for the DLC turnkey indicator. If the 
indicatory is "Y" do not calculate an order date and on job date. 
If the indicator is "N" proceed as code currently exists. Display 
indicator on each substep on the Needed and the All 
Requirements screens. In addition, an edit will be required so 
that a turnkey substep cannot be ordered in OSPCM. 

Management Reports - add report listing DLC Turnkey 
Requirements 



Performance Requirements: 

(list any performance requirements 
associated with this change) 

Dependencies: 

(list any defects or features that this 
enhancement is dependent on) 

Benefits: 

(Provide benefits in dollars, reduced Ability to track DLC turnkey operations in OSPCM as part of a 
headcount, time saving, etc, for doing engineering authorization, 
this work) 

Affected Components: (Check) (Check) 

Yes No 
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RTOC Instructions 

HELP x 

User Guides x 

Testing x 

Infra-structure 

Management Reports x 

Database x 

Job Entry x 

Materials Mgmt x 

OPEDS x 



Work-around: 

(is there a temporary work 
around?) 

(describe work around in 
detail) 



(Check) 
Yes 

X 



(Check) 
No 



Do not place DLC equipment or splicing for turnkey jobs into OSPCM. 
Back end report all equipment in "As Builts." 



Risks: 

(list factors that impact, Possibility lose tract of job requirements for equipment, 

positive/negative, not doing No inventory tracking. 

this change) Work will be added to the field technician to complete substeps in 

vendor activity. 



Business Rules: 

(list any business rules that 
should apply) 

Documentation Changes: 

(list affected documents JOB ENTRY USER GUIDE 

requiring change) JOB ENTRY INSTRUCTOR GUIDE 
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MATERIALS USER GUIDE 



Acceptance Criteria/Test Scenario: 

(list test scenarios required to Test scenarios to be provided by January 15, 1997. 
test change) 

Attachments: 

(copies of screens, reports, etc. Job Entry - Custom material screen 
before and after proposed Job Entry - Splicing screen 

change) Management Report - layout 

Signatures of Agreement: 
(add additional rows if necessary) 
BAE: 

Lead Analyst: 
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BAE Functional Requirement Document 



Table # 5989 

BAE Start Date: 03/26/1997 
BAE Comp. Date: 03/26/1997 
BAE Hours: 1 

CMVC Component Name: 

Associated Defect/Feature 4707 
No.: 

Target Release: Target Release Date: 

(give target release this needs to 2.0 (give target release date for this 04/01/1997 

be in) enhancement) 

Priority: 

(provide priority from 'feature priority' list - HI 
production hi through deferred low 

Revision No.: 
Reason for Revision: 

Subject: 

(brief description of change) Change step edits in Job Entry Ewo 

Introduction: 

(description of what system currently System currently allows no duplicate steps on the job. 
does, what needs to be changed, and Need to change edit to no duplicate steps on the print. 



BAE Name: Gail Deaton 
BAE Tele. No.: 977-3615 
LA Assigned: 
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why) 



This change is required to accommodate conversion job. 



Solution: 

(describe what the system will or 
should do and any general constraints 
or conditions that limit the solution) 



The system should edit each step number for duplicate entries. 
There should not be any duplicate step numbers for the print 
specified. Duplicate step number can be entered for the job. 



Change(s): 

(detailed description of change) - [add 
additional rows if multiple changes] 



Feature 4707 implemented the job level edit. The feature needs 
to be reversed. Example: there can be print 1 step 1; print 2 
step 1; print 3 step 1; etc. 



Performance Requirements: 

(list any performance requirements 
associated with this change) 



Should not change any current performance. 



Dependencies: 

(list any defects or features that this 
enhancement is dependent on) 



Benefits: 

(Provide benefits in dollars, reduced 
headcount, time saving, etc, for doing 
this work) 



Allows for the conversion of JMOS jobs into the OSPCM 
system without the changing of step numbers of the physical 
work prints. 



Affected Components: 



(Check) 
Yes 



(Check) 
No 
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RTOC Instructions 
HELP 

User Guides x 
Testing x 
Infra-structure 
Management Reports 
Database 

Interfaces: 

(list any legacy or new 
interface systems 
impacted by this 
change) 

(Check) 

Work-around: Yes 

(is there a temporary work 
around?) 

(describe work around in 
detail) 

Risks: 

(list factors that impact, 
positive/negative, not doing 
this change) 

Business Rules: 

(list any business rules that A step number is unique to the print, 
should apply) 

Documentation Changes: 

(list affected documents 1 . 

requiring change) 



(Check) 
No 

X 
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Acceptance Criteria/Test Scenario: 

(list test scenarios required to 
test change) 

Attachments: 

(copies of screens, reports, etc. 
before and after proposed 
change) 

Signatures of Agreement: 

(add additional rows if necessary) 
BAE: 

Lead Analyst: 



BAE Functional Requirement Document 



Table #6091 

BAE Start Date: 04/30/1 997 BAE Name: Gail W. Deaton 

BAE Comp. Date: 05/20/1997 BAE Tele. No.: 977-3615 

BAE Hours: 6 LA Assigned: 

CMVC Component Name: CONFIGURATION EDITOR 

Associated Defect/Feature 609 1 
No.: 

Target Release: Target Release Date: 

(give target release this needs to phase_2. 1 (give target release date for this 09/0 1/1 997 

be in) enhancement) 

Priority: 

(provide priority from 'feature priority' list - HI 
productionhi through deferredlow 

Revision No.: 
Reason for Revision: 

Subject: 

(brief description of change) 1 Add an edit to alert the user that a resource has been 

end dated. 
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Introduction: 

(description of what system currently 
does, what needs to be changed, and 
why) 

Solution: 

(describe what the system will or 
should do and any general constraints 
or conditions that limit the solution) 

Change(s): 

(detailed description of change) - [add 
additional rows if multiple changes] 



1 Currently an expired resource can be assigned in the 
configuration tables. A edit needs to be in place that will make 
a call to the employee editor to check the resource end date. 

1 When a user calls up a specific resource on any 
configuration table and tries to make updates to this resource, a 
call should be made to employee editor to see it this resource is 
expired. 

1 Resource Group/Work Type - When changes or 
additions are entered on this form, a call should be 
made to see if the resource has expired. If the resource 
has not expired, allow the user to continue with 
updates. If the resource is expired, allow only deletes. 

2 Resource Group/Wire Center Area - When changes or 
additions are entered on this form, a call should be 
made to see if the resource has expired. If the resource 
has not expired, allow the user to continue with 
updates. If the resource is expired, allow only deletes. 

3 Resource Group/W ork Type/Wire Center - Resource 
Group/Wire Center Area - When changes or additions 
are entered on this form, a call should be made to see if 
the resource has expired. If the resource has not 
expired, allow the user to continue with updates. If the 
resource is expired, allow only deletes. 

Implement an edit to check the expiration date of the RESID. If 
the expiration is before today's date, allow the delete. If the 
expiration is today or in the future, do no allow the delete. 
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Error message should read: THE RESOURCE FOR THIS 
UPDATE HAS EXPIRED. ONLY DELETIONS ARE 
ALLOWED FOR THE RESID. 
1. 



Performance Requirements: 

(list any performance requirements 1 Performance should not be affected by this feature, 
associated with this change) 

Dependencies: 

(list any defects or features that this 1 . 
enhancement is dependent on) 



Benefits: 

(Provide benefits in dollars, reduced 1 . The user will not be able to assign work on the 
headcount, time saving, etc, for doing Configuration Editor to a expired RESID. This will save 
this work) invalid inputs from the user and also serve to notify the user 

that the RESID is expired. 



Affected Components: (Check) (Check) 

Yes No 

RTOC Instructions 
HELP 

User Guides x 
Testing x 
Infra-structure x 
Management Reports 
Database 



Interfaces: 

(list any legacy or new 1 . 
interface systems 
impacted by this 
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change) 



(Check) (Check) 
Work- around: Yes No 

(is there a temporary work X 
around?) 

(describe work around in 1 . 

detail) 



Risks: 

(list factors that impact, 1 . 

positive/negative, not doing 
this change) 



Business Rules: 

(list any business rules that 1 . 
should apply) 



Documentation Changes: 

(list affected documents 
requiring change) 



Acceptance Criteria/Test Scenario: 

(list test scenarios required to 1 
test change prior to user 
acceptance) REQUIRED 

2 



Expire a RESID in Employee Editor. Next date - access the 
Configuration Editor and try to make a update. EMU should be 
generated that RESID is expired. 
Delete some information for this RESID. Verify the 
information is deleted. 
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Attachments: 

(copies of screens, reports, etc. 1 . 
before and after proposed 
change) 

Signatures of Agreement: 

(add additional rows if necessary) 
BAE: 

Lead Analyst: 



BAE Functional Requirement Document 



Table # 4652 



BAE Start Date: 10/07/1996 BAE Name: MARK SEAL 

GAIL DEATON 
LARRY RICE 

BAE Comp. Date: 11/05/1996 BAE Tele. No.: 977-3618 

977-3615 
977-7436 

BAE Hours: GAIL = 105 HOURS 

MARK = 102 HOURS 
LARRY = 45 HOURS 

CMVC Component Name: OSPCM-STAND ALONE 

Associated Defect/Feature 
No.: 

Target Release: Target Release Date: 

(give target release this needs to 2.0 (give target release date for this 6/01/1997 

be in) enhancement) 

Priority: 

(provide priority from 'feature priority' list - HI 
production_hi through deferred_low 

Revision No.: 
Reason for Revision: 
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Subject: 

(brief description of change) Make necessary software changes in order to deploy OSPCM 

system as a stand alone. This means without the mechanized 
interface with the OPEDS system. 



Introduction: 

(description of what system currently Currently the OPEDS system creates data and mechanically 
does, what needs to be changed, and inputs that data into the OSPCM system. The OPEDS system 
why) also receives completion data mechanically from the OSPCM 

system. These two interfaces handle only the data necessary for 
interaction between these two systems and does not include 
data for other down stream systems such as (FP) financial 
processor. 



Solution: 

(describe what the system will or OSPCM will be modified to handle a manual encoding process 

should do) which will encompass all the necessary data for the down 

stream accounting systems. OSPCM will also be modified, and 
an interface created to pass completion information to the down 
stream accounting systems. 



Code has been developed in OPEDS by Watson Dorn to accept 
the data feed from OSPCM. This code adds data that is 
currently kept only in the OPEDS system and does some 
translations and then passes the information Requirement onto 
the FP (Financial Process) system. It is assumed that this code 
and the projected OPEDS to FP interface will be utilized when 
OSPCM is modified for a stand alone deployment. The overall 
procedure will encompass a very detailed level of complexity 
which is necessary in order to achieve the acceptable level of 
accuracy. It is assumed that is existing code along with Mr. 
Dorn and some part of his development team will be 
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incorporated into the OSPCM team responsible for the OSPCM 
Stand alone development effort. It should also be noted that 
some changes to this existing OPEDS code must be made in 
order to read data from OSPCM rather than the OPEDS data 
base. 



Change(s): 

(detailed description of change) - [add The existing code for the OPEDS to FP interface will be moved 
additional rows if multiple changes] to the OSPCM system and will continue to feed the down 

stream financial system. By using this "already developed" 
code, the changes that will be needed are to add additional 
information in OSPCM and feed the OPEDS/FP interface code. 
This additional information is the data that would have been 
provided by the OPEDS data base if it were completed. All 
historical material reporting information which includes 
original, previous and correcting records will also be handled 
by this code. The changes in OSPCM that will be necessary are 
to the modules. . Job-Entry EWO, Job-Entry Other, Scheduling, 
Management Reports, Billing and Reporting, Workstation and 
OPF Table. 

1 OSPCM FUNCTIONAL DECOMP'S - UPDATE 

• Functional decomps will be revised to include the 
process of using the added code and the changes 
which include the additional data fields. 

2. OSPCM "HELP" - UPDATE 

• All of the "HELP" information on the affected 
screens and modules will be revised to reflect these 
changes. 
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3. OSPCM USER/INSTRUCTOR GUIDES - 
UPDATE 

• User guides and instructor guides will be to include 
these changes in and additional data fields. 

4. OSPCM/OPEDS COMPLETION CONTRACT - 
STANDALONE 

• OSPCM will maintain the existing substep 
completion contract to be used in the event that the 
OPEDS system will eventually be completed. For a 
stand alone application a new substep completion 
contract will be developed and will contain all of 
the information necessary for the OPEDS/FP code 
to work correctly with the accounting system. This 
new substep completion contract (stand alone 
substep completion contract) will contain all of the 
data presently in the existing contract along with 
additional information as described below. 

• These are not all fields but include the additions. OSPCM 
stand alone substep completion contract fields: 



name Character type Length 

jobnbr alpha/numeric 9 

print jibr alpha/numeric 4 

stepnbr alpha/numeric 6 

substep_nbr alpha/numeric 3 

cmpl_dt alpha/numeric 8 

rco alpha/numeric 8 

rcc alpha/numeric 8 

frc alpha/numeric 5 

wc alpha/numeric 8 

work_act alpha/numeric 4 

work_env alpha/numeric 1 

direct_to_code alpha/numeric 1 

excpt_glc alpha/numeric 1 
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matenai_item 


aipna/numenc 


1 ^ 


cpr_cd 


alpna/numeric 


1 n 

1U 


cpr_ind 


alpha/numeric 


1 


mic__cd 


aipna/numenc 


i n 

IU 


pi_cd 


aipna/numenc 


i 
i 


order_qty 


numeric 


o 
0 


record_qty 


numeric 


o 
O 


year 


numeric 


4 


ret_dt 


numeric 


o 

o 


taxdi strict 


numeric 


!> 


pcte__qtyret_ind 


numeric 


3 


cmcenc 


alpha/numeric 


8 


cmc_rpt 


alpha/numeric 


8 


misc_cd 


alpha/numeric 


3 


misccdvalue 


alpha/numeric 


16 



• MISC CODES - Additional misc codes will be added to 
the drop down list on the work reporting screen. These 
codes are explained in this document on an individual basis. 
The new substep completion contract for a stand alone 
application will operate the as the current contract that is 
that multiple misc codes can be generated and passed with 
each substep completion. 

• CMC -Two new fields will be added to the substep 
completion contract to identify the cmc responsible for 
encoding the job and the cmc responsible for reporting the 
job completion. When the substep completion contract is 
created the fields "cmc_enc" and M cmc_rptBecause" will be 
populated with the cmc cd for which the job was encoded. 

• CPR CODE - The cpr code will be added to the substep 
completion contract for all material items. The cpr code can 
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be obtained using the material item in the CID table when 
the substep completion contract is created. Note that if the 
cprjnd is M N" then there will not be a cpr_code 

• CPR IND - The cpr indicator will be added to the substep 
completion contract for all material items. The cpr 
indicator can be obtained using the material item in the 
CID table when the substep completion contract is created. 
Note that if the cpr_ind is "N" then there will not be a 
cpr_code 

• MIC CODE - If a material item has a MIC code associated 
then this code will be populated in the substep completion 
contract in the "misc_cd" field. The mic code will be 
obtained using the material item from the CID table. 

• PI INDICATOR - The pi__cd field will be added to the 
substep contract and populated based on the material item 
in the CID table. If the misc_cd in the mtl_misc_cd table is 
"PI" then the misc code value is entered on the substep 
completion contract in the pi_cd for the material item on 
the substep. 

• TAX DISTRICT - A new field will be added to the 
substep completion contract and will be called "tax dist. 
This field will have a value of 5 numeric characters. 

• YEAR PLACED - A misc code of "YPL" will be used for 
a removal or abandon work action on added substeps. The 
value of this misc code will be 4 numeric characters and 
will be populated on the substep completion contract. 
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"YEAR" 'field/- The will be populated for on the front 
end. When these are completed the encoded year placed 
will be populated in the "YEAR" field on the substep 
completion contract. If there is a year placed encoded on 
the job entry screens and at the time of substep 
completion the misc of YPL is used then the value of 
the misc code is used to populate the YEAR field in the 
substep completion contract. 

MULTIPLE MODULES -TAX DISTRICT 

• A new field of TAX" will be added to the Job- 
entry screens to facilitate the entry of tax districts. 
This field will be available on the job level screen 
and will then default to the placing screen and 
removal screen. If a substep has a different tax 
district then the user can over type the default. Pick 
list should be available in a drop down. The drop 
down should list all the valid tax district codes 
associated with the wire center entered. On the 
substep level, if a wire center is changed from the 
job level default, the tax district in the drop down 
should be associated with the new wire center 
entered. Tax districts will be validated against the 
Wire Center Area table in OSPCM. Currently tax 
district does exist in this table. 

• In work reporting the misc code of "TAX" will be 
added to the list of valid misc codes to enable the 
user to provide a tax district on added substeps. For 
encoded substeps, when the substep is completed, 
the misc code of "TAX" should be used when 
changing the encoded tax district. If no change is 
needed for an encoded tax district on a substep then 
no misc code is necessary. The system will use the 
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misc code value for TAX from the "mtl_mis_cd" 
table if any exists to populate the substep 
completion contract If there is not a misc code of 
"TAX" in the mtl_misc_cd table then the encoded 
tax district from substep_ewo will be used to 
populate the substep completion contract This same 
logic will apply to substep completions on the 
BULK reporting screens. 

• For contractor completed substeps the misc code 
of TAX will not be used. When a contractor 
completes a substep the tax district value that was 
encoded will be used to populate the substep 
completion contract. When a contractor adds a 
substep, it is cloned from another substep and the 
tax district will follow. When the substep 
completion contract is created for contractor 
substeps then the tax district field will be populated 
using the tax district value in substep ewo. 

6. JOB ENTRY MODULE - PERCENT 
OWNERSHIP 

• A new field of TCP or "PERCENT OWNERSHIP" 
will be added to the job-entry screens at a Job level 
and the value will apply to all of the placing 
substeps on the job. The default value will be "100" 
and can be over typed at a substep level if 
necessary. No decimal should be in this field. This 
field will be added to the substep_ewo table and 
will be passed at a substep level in the substep 
completion contract. 
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7. JOB ENTRY MODULE - MATERIAL DROP 
DOWN 

• The job entry placing screen will be enhanced to 
add three additional fields in the material drop 
down box. The new fields will be : 

• material category 

• material subcategory 

• stock indicator 

• Sort alphabetically and the order of the fields 
should be MATERIAL SHORT DESC / 
MATERIAL CATEGORY / MATERIAL 
SUBCATEGORY / STOCK INDICATOR 

• Incorporate edit in drop down to show only the 
materials in the same material category that is 
derived from the material description entered. 

8. MULTIPLE MODULES - EXPAND JOB 
DESCRIPTION 

• Expand the job description field to 65 characters. 
This expansion will affect: 

• Job entry information screen, job 
description field 

• Scheduling screens that display 
the job description 

• Reports that display the job 
description 
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9. JOB ENTRY - EDIT ON STEP NUMBERS 

• Add edit on step numbers in Job Entry to make step 
number unique across the entire job. Currently the 
step number is associated with a print. Example, a 
job can have print 1 step 1 and print 2 step 1. The 
edit should disallow the duplication of step 
numbers. 

Business Rule - Step number should be unique across 
the entire job. 



10.- MULTIPLE MODULES - ADD WORK ID FIELD 

• Add an ID field to further identify a work 
location, this field should be 6 characters and 
accept numbers and alpha characters. This 
field will be added to: 

• Job-entry screens of placing, splicing, 



other and removal 



order screens 



screens 



Scheduling screens 

Work station reporting screens 

Contractor work 

Contractor reporting 

Job-entry Other screens 

Inspections 

Reports 



• A edit is needed to require that the ID number is 
unique across the entire job. 

• Business Rule - ID number should be unique across 
the entire job. 
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11. WORKSTATION - RE-DESIGN WORK 
REPORTING SCREEN 

• Re-Design the work reporting screen to fit on a 15" 
monitor. We will maintain the substep grid and 
make the column widths adjustable. Change the 
column headings to reflect the following from left 
to right. Job, Print, Step, ID#, Work Act, Work 
Env., FRC, Type, Cmt, RB, Rmk, Mtl, Mrs, Status, 
Address, we will make the screen larger, the detail 
information tabs will be displayed on the lower 
portion of the screen. When the screen opens the 
cursor will be focused on the first substep and the 
details tab will reflect the detail information on that 
substep. The details icon will be eliminated. The 
address field on the materials detail tab will be 
removed and the splicing configuration grid from 
Job entry will be displayed in this area for splicing 
sub steps. The name of the first tab will be changed 
from "Materials" to "Details". 

12. SCHEDULING - ADD COLUMN FOR WIRE 
CENTER 

• Add to all scheduling screens an additional column 
which will reflect the job level wire center. This 
column will be inserted following the activity 
number column. 

• Add to all scheduling screens an additional column 
at the far right called Job Description. This will be 
a 65 character field and will be sizable by the user. 
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13. JOB ENTRY - "HOT KEYS" 

• Develop "Hot Keys 89 to allow the user to jump from 
grid to grid (without using the mouse) on the job 
entry placing, splicing, other and removal screens* 

• File menu drop down should provide "Hot Key" 
mapping 

14. JOB ENTRY - LAUNCH PRICING 

• The ability for the user to access pricing without 
closing job entry and opening pricing. 

• The user should be able to launch pricing 
from job entry print/step/substep outline. 

• The user should not have to reopen the job 
that is currently being encoded. The job 
number should be carried forward into 
pricing. 

• Business Rule - Pricing cannot be 
executed unless the job is configured. 

• Business Rule - Pricing cannot be executed 
while step screen is open. 

15. PRICING - DIALOG BOX / CHANGE REPORT 
NAME 

• Change reports headings and buttons to 
PRELIMINARY and FIRM 

• change "Unapproved" term to 
"Preliminary" 

• change "Approved" term to "Firm" 
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• A dialog box should be displayed upon exiting 
pricing to prompt "Do you want to FIRM this 
price?". 

• Display if the job has not been FIRMED 

• Display if the job has had pricing changes 
since last FIRM 

16. JOB ENTRY - POWER-SEARCH 

• The job entry open existing job screen should go to 
the job # in the job number grid as it is keyed in the 
job number field. 

17. JOB ENTRY - CONTRACT ITEMS BID SCREEN 

• Give the user the ability to access the Contract 
Items Bid Screen after a successful configuration. 

• Currently the job must be approved in the 
pricing module before the user can access 
the Contract Items. Remove this edit. 

18. JOB ENTRY - RESIZE INDICATOR 

• A new indicator "RSIZE" will be added to the job- 
entry placing and removal screens at a substep level 
in order to identify when a material item is 
associated with resizing a terminal This indicator 
will default to "N" for no. "Y" in this field will 
indicate that the material item is associated with the 
resizing of a terminal and will be used to generate 
the CPR ADJP code of "M" which will be 
populated in the substep completion contract "N" in 
this field will indicate that the material item is not 
associated with a resize and will generate a "NULL" 
entry in the CPR ADJP field on the substep 
completion contract. 

• Two new work actions will be created in Job-entry 
for use on the "OTHER" type substep screen to 
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facilitate the identification of CPR resizing 
information. The work actions will be "PCPR and 
RCPR". The quantity field will indicate the size of 
the terminal when either of these work actions are 
entered. Upon completion of a substep with either 
of these work actions the CPR ADJP code will be 
set to "R" for those substeps with a work action of 
RCPR and "P" for those substeps with a work 
action of PCPR. The substep completion contract 
will be populated with the usual data with the 
following completion exceptions and these will 
apply to substeps with either work action 
(PCPR. .RCPR). 

• The material_tem field in the substep 
completion contract will be populated with 
"TERM-[xxxx]pr" where the "xxxx" is 
equal to the "wa_qty" field in substepewo. 

• The record qty field in the substep 

completion contract will be populated with 
ii | H 

19. JOB ENTRY - CLONE JOB/SUBSTEP. 

• Clone Job - Additional functionality will be added 
to job entry to facilitate cloning of a Job. An icon 
will be added to the Job Details screen in Job entry. 
The user will select a template job for the job to be 
cloned and then selects the icon. A dialog box is 
displayed allowing the user to enter job level details 
for the new job. The user enters the Job level 
details and either clicks "OK" or "CANCEL". If the 
user clicks cancel the dialog box disappears and the 
new job is not created. If the user enters a job 
number and clicks the OK then the Job number is 
to insure it is formatted correctly and does not 
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already exist. Once edited, the system creates the 
entire job with and substep data. 

• Business Rule - Clone ID field as blank 

• Business Rule - Clone address field as blank 

• Clone Substep - An icon will be to the substep 
entry screens. When a substep is entered and focus 
is on that substep line, and the user clicks on the 
clone icon a dialog box will be displayed. The 
dialog box will ask how many substeps are required 
to be cloned. The dialog box will have "CANCEL 
and OK" buttons. When a number is entered and the 
OK button selected the system will create the 
additional substeps. If the user selects cancel then 
no new substeps are created. 

• Business Rule - Clone ID field as blank 

20. MULTIPLE MODULES - ADVANCED 
RETIREMENT 

• A new indicator will be added to the substep ewo 
table called RETJND. This indicator will default to 
"N" for no. The purpose of this indicator is to 
indicate that material has been retired and that 
retirement has been sent to the financial system. A 
new field in the substep completion contract will be 
added called "ret". This field will be populated from 
the substep_ewo table with a "N" for no and " Y" for 
yes. 

When a substep is encoded in job entry it may or 
may not have a retirement date entered at that time. 
If a retirement date is entered (that is... the date 
comes from the engineer), then the date is populated 
in the substep_ewo table in the retirement date field. 
The user can advance retire the material using this 
date by going to the Bulk Reporting screen and 
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displaying the job and clicking the advance retire 
icon. A dialog box is displayed showing the 
retirement date entered on the job entry screen. If 
the user does not want to retire the material at that 
time he can select CANCEL and nothing happens. 
If the user wants to go ahead and advance retire the 
material then he selects OK and the substep 
completion contract is populated. When the 
completion contract is populated for the advance 
retirement the RET field is set to "N" according to 
the substepewo table. Once the contract is . 
populated successfully, the system will change the 
indicator in the substep ewo table from "N" to "Y". 
This indicates that the material has been retired 
even though the substep is not complete. When the 
substep is completed the completion contract is 
populated again and this time the RET ESED in the 
substep ewo table is set to "Y" so the RET field in 
the completion is set to "Y" indicating the material 
has already retired. The u ret_dt field in the substep 
completion contract is with he advance retirement 
date. 

• When a substep is entered In job entry and a 

retirement date is not provided by the engineer the 
RET IND will default of "N". If the user wants to 
advance retire material he will access the Bulk 
Reporting screen and display the Job. The user then 
clicks on the advance retirement icon and a dialog 
box is displayed asking for a date. The user will 
enter the advance retirement date and click OK. The 
system will populate the substep completion 
contract and the RET field will be "N"...same as the 
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RET IND in the substep_ewo table. Once the 
completion contract is successfully executed the 
RET IND will be set to "Y" meaning that the 
material has been advance retired. 

• When the substep is completed the substep 
completion contract is populated and the RET field 
is populated with a "Y" indicating that the material 
has already been retired. The "ret_Jf will be 
populated with the advance retirement date. 

21. JOB ENTRY-YEAR PLACED EDIT 

• When a removal type substep is entered on the job 
entry screens an additional edit will be performed to 
check the material item and cpr indicator. If the 
material item has a cpr indicator set to "Y" then the 
year placed should be a required entry. If the cpr 
indicator is set to "NT then the year placed entry is 
not required. 

22. OFF TABLE - JOB CLOSE INTERVAL 

• A new field will be added to the OPF table at a cmc 
level and will be called the Job Close Interval. The 
value in this table field will be 2 numeric characters 
(00 to 99) and should be user controlled and at a 
CMC level. The regional default will be 10. This 
will be the interval (in days) between the Job End 
Date and the Job Close Date. A batch process will 
be added to check the Job End Date and the Job 
Close Interval and if necessary populate the Job 
Close Date. 

• Example: The Job End Date is 6-1 -1996. The Job 
Close Interval is set to 10. If the current date is 10 or 
more days past the Job End Date then the system will 
populate the Job Close Date with the current date. 
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NOTE: Once a job is closed it can not be re-opened 
for any reason. 

• The routine that will populate the Job End Date is as 
follows; When the last substep on a job is completed 
the system will check the progressive engineering 
indicator. If the indicator is set to T then no further 
action is required at that time. If the indicator is set to 
"N" when the last substep is completed then the 
system will check the 1NV CD for all substeps. If 
this code is populated with a "N" or "I" for all 
substeps then the system will populate the Job End 
Date with the current date. 

• When the progressive engineering application 
indicator is set to "Y" and the user changes the 
indicator to "N" then the system will do a check to 
see if all substeps on the job are complete and the 
Inv_cd is set to "N" or "I". If there are substeps that 
are not complete then no further action is needed. If 
there are substeps with the Inv_cd populated with a 
code other than "N" or "I" then no further action 
necessary. If all of the substeps are complete and the 
Inv_cd is populated with an "N" or T then the system 
will populate the Job End Date with the current date. 

• If a job has the Job End Date populated with a date 
and a substep is uncompleted or if a new substep has 
been added to the job then the Job End Date will be 
removed. Once the additional substeps are completed 
then the system will go through the process as 
described above to populate the Job End Date and the 
Job Close Date fields. 
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23. MANAGEMENT REPORT - JOB CLOSE 
REPORT 

• A mechanized Job Close report will created to list all of 
the jobs that have closed in the current week. The report 
will be sent mechanically to the cost office. This feed 
can probably be accomplished with a bufit file sent via 
E-MAIL The E-MAIL address for the cost office will be 
held in the OPF table in a new field called 
costmailadd. 

• Management Reports will provide the same data on line 
in OSPCM on a similar report. This report will be 
requested by CMC and Date. The date will identify the 
particular week that data is being requested for. In 
addition a second report will be developed and available 
on a weekly and monthly basis which will be a list of all 
jobs that closed for the current month. On this report 
additional information will be included such as percent 
of open jobs that closed, etc. 



24. TABLE - OPEDS WORK ACTION 
CONVERSION 

• Presently the code developed by Watson Dorn 
includes a conversion work action table and it is 
assumed that this table will continue to be used in a 
stand alone application. The four work action codes 
that are used by the financial system are PLAC, 
REMO, PCPR and RCPR. 

25. TABLE - OPF 

• Additional information will be added to the OPF 
table at a regional and/or cmc level. The table will 
hold the default values for contract work involving 
(depth, width, diameter, new/existing). When the 
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system searches this table it will look at a CMC 
level and use the information available. If there is 
no information at a cmc level then the system will 
look at a regional level. If no information exists, 
then the user will have to input the data on the job 
entry placing screen. This is an existing feature 
[JBNTRY12.DOC] in the current application. 

26. MANAGEMENT REPORT - PICS/DCPR 

• A management report will be created to reflect the 
same data being retrieved from JMOS today. That 
is information associated with completed substep 
involving COE, DLC equipment. See attachment 

27. JOB ENTRY - EXCEPTION GEO LOG 

• A new field "EX GL" will be added to job entry 
removal screen for removal type substeps. This 
field will be used to enter the exception GL for 
removal substeps associated with COE and DLC 
equipment. When the FRC associated with this type 
of equipment is used then the system should edit 
this field and require that a valid GL has been 
entered. 

28. SCHEDULING -ADD JOB DESCRIPTION TO 
SCHEDULING SCREENS 

• Add a new column on the "Current Week, Next 
Week, 20 week limited and unlimited scheduling 
screens. This new column will be called "JOB 
DESCRIPTION". This new column will be the last 
column on the right hand side of all of the screens. 
The 65 character Job description will be populated 
in this column for each and every activity on the 
screen. The grid will continue to be adjustable and 
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will be left to the user to change and save the 
column widths. 

29. OSPCM - WINDOWNS NT COMPATABILE 

• The following should be designed to work on 
Windows NT 
•OSPCM 

•OSPCM managments reports 
•Chameleon 
•Focus for Windows 
•Navigator contracts 

•A letter should be drafted to all Outside Plant 
Contractors to assure compatibility of software 

30. ADDITIONAL ITEMS - FEASABILITY 

• The following items will be evaluated 
during the detail design process to 
determine what if anything, can be done 
and the best way to accomplish these items. 

• Default the work action on the job entry 
placing screen to "PLAC". 

• Default the work action on the job entry 
splicing screen to "SPL M . 

• On the job entry placing screen, default the 
record qty and order qty on non cable 
material items to 

• On the job entry placing screen, default the 
order qty to "1" on items when the record 
qty of "1" is entered. 

• Add description to the work actions on the 
drop down menu on the job entry screens. 
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31. JOB ENTRY - PERFORMANCE 

• Edits are performed on each field as entered for the 
job entry screens. The system is slow in performing 
this edit and allowing the user to continue to the 
next field of input The response time of the system 
should be improved for these screens. 



Performance Requirements: 

(list any performance requirements 
associated with this change) 



Job entry material drop downs may affect performance goal of 
2 seconds. No significant difference in performance should be 
seen when opening the scheduling screens due to adding the 
Job Description field at an activity level. 



Dependencies: 

(list any defects or features that this 
enhancement is dependent on) 



OSPCM interface to FP is dependent on the use of Watson 
Dorn's existing code. 



Interfaces: 

(list any interfaces that this 
enhancement is dependent on) 



Job closed reports to Accounting 
PICS/DCPR reports 
Interface with the FP system 



Benefits: 

(Provide benefits in dollars, reduced 
headcount, time saving, etc, for doing 
this work) 



Benefits in dollars &00.00. 
No reduced head count. 

Some time saving on encoding screens and very little if any 
on the time reporting screens. No savings on scheduling 
screens. 



Affected Components: 



(Check) 
Yes 



(Check) 
No 



Job - Entry 
Pricing 



x 
x 
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Scheduling 

Workstation 

Contractor Reporting 

JE - Other 

HELP 

User Guides 

Testing 

Infra-structure 

Management Reports 

Database 

Work-around: 

(is there a temporary work 
around?) 

(describe work around in 
detail) 

Risks: 

(list factors that impact, 
positive/negative, not doing 
this change) 



x 
x 
x 

X 
X 
X 
X 
X 
X 
X 



(Check) 
Yes 



(Check) 
No 

X 



• The items critical to passing material to the down stream 
system (FP) must all be developed for OSPCM to work as a 
stand alone system. 

• The items that are M nice to have or allegedly reduce user work 
content are not critical to making OSPCM a stand alone 
application. 

• Change of current personnel or a personnel reduction of 
OSPCM team members will have a severe impact on a June, 
1997 deployment date. 

• Watson Dom code for FP interface not compatible with OSPCM or 
necessary changes not made by his development team members. 

• Budget funding 
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Business Rules: 

(list any business rules that See Items above, 
should apply) 



Documentation Changes: 

(list affected documents 
requiring change) 



Test Scenario: 

(list test scenarios required to 
test change) 



• HELP 

• User guides 

• Instructor guides 

• Functional decomp ' s 

• Data Model 

• Data dictionary 

To be furnished by Feb 01, 1997. 



Attachments: 

(copies of screens, reports, etc. 
before and after proposed 
change) 



• Job entry screens 

• Pricing 

• Scheduling 

• Work station 

• Contractor Reporting 

• JE-Other 

• Management Reports 
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Signatures of Agreement: 

(add additional rows if necessary) 

BAE: 

BAE: 

BAE: 

BAE: 

Lead Analyst: 
Lead Analyst: 
Lead Analyst: 
Lead Analyst: 



BAE Functional Requirement Document 



Table #6212 



BAE Start Date: 05/06/1 997 BAE Name: Gail Deaton 
BAE Comp. Date: 05/06/1997 BAE Tele. No.: 977-3615 
BAE Hours: 1 



CMVC Component Name Job Entry - EWO 

Associated Defect/Feature No.: 



Target Release: Target Release Date : 

(give target release this needs Phase_2. 1 (give target release date for this 09/1 997 

to be in) enhancement) 

Priority: 

(provide priority from 'feature priority' list - med 
productionjii through deferred_low 

Revision No.: 
Reason for Revision: 



Subject: 

(brief description of change) 1 . Add percent ownership to the removal screen 
Introduction: 

(description of what system currently 1 . Currently the system is hard coded to enter 100 percent 

does, what needs to be changed, and ownership for BellSouth. In the case of partial ownership, 

why) OSPCM cannot generate the appropriate transaction to FP. 
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Solution: 

(describe what the system will or 
should do) 



1 . OSPCM should allow the entry of percent ownership 
for removal items. 



Change(s): 



1 . Add the field "PCT" for percent ownership on the 
removal screen for Job Entry - EWO. Default the entry in this 
field to 100. Allow the user to overtype with changes. 



Performance Requirements: 

(list any performance requirements 
associated with this change) 



1. 



None 



Dependencies: 

(list any defects or features that this 
enhancement is dependent on) 



1. 



Benefits: 

(Provide benefits in dollars, reduced 
headcount, time saving, etc, for doing 
this work) 



1 . Allows for the proper reporting of material removal 
items that are partially owned. 



8. Affected Components: 



(Check)(Check) 
Yes No 



RTOC Instructions 
HELP 

User Guides 
Testing 
Infra-structure 
Management Reports 
Database 



x 



(Check) 



(Check) 
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Work-around: Yes No 

(is there a temporary work x 
around?) 

(describe work around in 1 . The work around is to default "PCT" to 100 for all removal 

detail) items. 



Risks: 

(list factors that impact, 1 . 

positive/negative, not doing 
this change) 



Business Rules: 

(list any business rules that 1 . 
should apply) 

Documentation Changes: 

(list affected documents 1 . 

requiring change) 



Acceptance Criteria/Test Scenario: 

(list test scenarios required to 1 . Enter a substep on the removal screen. 

test change prior to user Change to default from 100 to 80. 

acceptance) REQUIRED Complete the step and follow the transaction to FP. 



Attachments: 

(copies of screens, reports, etc. 
before and after proposed 
change) 

Signatures of Agreement: 

(add additional rows if necessary) 
BAE: 

Lead Analyst: 
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BAE FUNCTIONAL DOCUMENT 

Table # 6249 FS 

BAE Start Date: 04/15/1997 BAE Name: Mark Seal 

BAE Comp. Date: 04/18/1997 BAE Tele. No.: 205-977-3618 

BAE Hours: 10.5 LA Assigned: 

CMVC Component Name: WORKSTATION — JOBENTRY EWO — MATERIALS 

MODULES 
Associated Defect/Feature No.: 6249 



Target Release 

(give target release this 
needs to be in) 



Target 

2.01 
2.1 



Release Date: 

(give target release date 
for this enhancement, if 
required 



Priority: 

(provide priority from 'feature HI 
priority' list - number 
preliminary assigned by SME) 



Revision No.: 
Reason for Revision: 

Subject: 

(brief description of change) 1 . ADD, CHANGE AND DELETE EDITS 

TO HANDLE THE ENCODING, ORDERING, 
RECEIPTING, INVENTORYING, REPORTING 
AND DISBURSEMENT OF ASSEMBLY ITEMS 
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Introduction: 



(description of what system 
currently does, what needs to be 
changed, and why) 



HANDLE ASSEMBLY ITEMS CORRECTLY FOR 



EXAMPLE: 



1. 



CURRENTLY THE SYSTEM DOES NOT 



• NON-ASSEMBLY MATERIAL ITEMS, SUCH AS 
CABLE, CAN BE ORDERED AS PART OF AN 
ASSEMBLY. 

• THERE IS A POTENTIAL FOR NOT ORDERING ALL OF 
THE ITEMS IN AN ASSEMBLY. 

• SINCE OSPCM INVENTORIES XPIDED AND NON-XPIDED 
ASSEMBLY ITEMS DIFFERENTLY, THERE ARE 
PROBLEMS WHEN THE USER COMPLETES THE 
SUBSTEPS FOR THE FACTORY ADD-ON ITEMS. 

• THE USER WOULD NOT BE ABLE TO RECEIPT THE 
CABINET IN AN ASSEMBLY THAT HAD AN XPIDED ADD- 
ON IF IT WAS NOT THE FIRST ITEM ON THE ORDER. 

• SINCE CABINETS ARE MAINLY PLACED BY A 
CONTRACTOR AND CWIS ARE NOT GENERATED FOR 
ANY ADD-ON ITEMS, THE SUBSTEPS FOR ANY FACTORY 
ADD-ON ITEMS WOULD NEVER GET COMPLETED 
BECAUSE THEY DON'T APPEAR ON THE CONTRACTORS 
SCREEN. 



Solution: 



(describe what the system will 
or should do and any general 



1. 



Change the system to ensure that an assembly item is encoded 
correctly. 



constraints or conditions that 



limit the solution) 



2. 



Change the system to ensure all items in an assembly are 
ordered at the same time. 
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3. Change the system so that the user can only receipt the cabinet 
within an assembly item and have the system auto-receipt the add- 
on items. 

4. Change the system so that only the user must complete only substep 
that contains the cabinet and have the system auto-complete the 
add-on items. This will be for work reporting, bulk reporting and 
contractor reporting. 



Change(s): 

(detailed description of 
change/addition) - [add 
additional rows if multiple 

changes] *■ JOBENTRY 

1 . Remove any existing edits referring to XPIDS (A 
PEDed item beginning with an "X"). This will 

allow the system to handle all types of PEDed 
materials with assembly codes. 

2. Business Rule: Material Items having an 

assembly indicator = "Y", must be encoded with an 
assembly code. Add additional edits to the Jobentry 
screens so that when material is entered without an 
assembly code, the system will check the Assembly 
Indicator in the OSPCM MATERIAL ITEM TABLE. If 
the Assembly Indicator is set to "Y", then return an 
error message to the user saying THIS MATERIAL 
ITEM CANNOT BE ENTERED WITHOUT AN 
ASSEMBLY CODE". If the Assembly Indicator is set 
to "N", then allow the entry. 

3. Business Rule: If an assembly is encoded, one of the 
substeps with that assembly code in that step must 
be for a cabinet having a subcategory code of 
"CABINET-HW" or "CABINET=HW&Pr\ Add 
additional edits to the Jobentry screens so that when 
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material is with assembly the system will check the 
Assembly in the OSPCM MATERIAL ITEM. If the 
Assembly Indicator flag is set to "Y", then an additional 
check will be made to all other material entered on the 
same Step with the same assembly code. A substep 
having a cabinet description from the Category of 
Circuit_Eqpt and the Sub-Category of "CABINET- 
HW" or "CABINET-HW&PI must exist with the same 
assembly code. If a cabinet description from the 
Category of Circuit Eqpt and the Sub-Category of 
"CABINET-HW" or "CABINET-HW&PI" does not 
exist, then return an error message saying THIS ITEM 
CANNOT BE ENTERED WITHOUT A CABINET 
WITH THE SAME ASSEMBLY CODE ON THIS 
STEP." If a cabinet description from the Category of 
Circuit_Eqpt and the Sub-Category of "CABINET- 
HW" or "CABINET-HW&PI" does exist and has the 
same assembly code then allow the entry. 
4. Business Rule: Material Items having an 

assembly indicator = "N", cannot be encoded with 
an assembly code, unless the material item has a 
subcategory code of "CABINET-HW" or 
"CABINET=HW&PL When material is entered and 
an assembly code is entered, the system will check the 
OSPCM MATERIAL ITEM TABLE. If the item 
entered has an Assembly Indicator flag set to M N", then 
check to see if the material item is in either of the sub- 
categories of "CABINET-HW" or "CABINET- 
HW&PI" under the category of CIRCU1T-EQPT. If the 
item is not in one of these sub-categories then return an 
error message to the user saying "AN ASSEMBLY 
CODE IS NOT ALLOWED ON THIS MATERIAL 
ITEM". 
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5. Business Rule: Only one cabinet may exist per 
assembly code within a job step. If the assembly 
indicator is "N" and the item has a subcategory of 
"CABINET-HW" or "CABINET-HW&PI", then verify 
that only one item from these sub-categories exist with 
the same assembly code on the same step. If only one 
cabinet exists then allow the entry. If the user is 
attempting to enter more than one cabinet per assembly 
then return an error message saying "NO MORE 
THAN ONE CABINET IS ALLOWED FOR EACH 
ASSEMBLY CODE". 

6. Business Rule: If a cabinet is encoded with an 
assembly code, there must exist at least one substep 
in that assembly for factory add-on material on that 
step. If the user enters a cabinet description from the 
Category of Circuit_Eqpt and the Sub-Category of or 
"CABINET-HW&PI" with an assembly code then at 
least one other substep with a material item having an 
assembly indicator equal to "Y" must have the same 
assembly code on the same step. If no other of these 
substeps exist, then return an error message saying 
"FACTORY ADD-ON MATERIAL MISSING FROM 
THIS ASSEMBLY". 

7. Business Rule: Cannot a substep to an assembly item 
if the cabinet for that assembly item has already been 
ordered, If the user attempts to add a material item with 
an assembly code after the assembly item has been 
ordered then return an error message saying "CANNOT 
ADD MATERIAL ITEMS TO A MATERIAL 
ASSEMBLY ITEM THAT HAS ALREADY BEEN 
ORDERED". 
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8. Business Rule: Assembly codes are 

alphanumeric and the field size is 1. Do not allow the 
user to type in any other character other than A-Z 
or 0-9. 

2. MATERIALS ORDERING & RECEIPTING 

1 . Remove any existing edits referring to XPIDS (Except 
the one that ensures that the XPIDed item is the first 
item on the order. See #3 below.). This will allow the 
system to handle all types of PIDed materials with 
assembly codes. 

2. Change the material application to add an edit to 
insure that all items with the same assembly code on a 
step are ordered at the same time. This needs to be true 
from the "Show Needed Requirements" option and the 
"Show Today's Requirements" option. Normally the 
cabinet will have the longest ship interval so the system 
should calculate an order date for each item in the 
assembly based on the cabinet order date. 

3. The order process should continue to insure that if 
ordering an XPIDed item that it be the first item on the 
order. Usually the cabinet is XPIDed, but if ordering a 
non-XPIDed cabinet and an XPIDed add on item, the 
XPIDed add-on item must be the first item on the order. 
CAPRI has a business rule which requires that the 
XPIDed item, if one exists, be the first item on the 
order. If multiple XPIDed items exist on the order, it 
doesn't matter which one comes first. 

4. Change the materials "Order Receipting Process" so 
that when items with assembly codes are receipted, 
only the cabinets are receipted by the user. Any add on 
items should be auto-receipted by the system when the 
cabinets are receipted in OSPCM. Do not create order 
receipt transactions for the factory addition items, but 
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change their substep material status to "R". When 
receipting, only the cabinet should be placed in the 
inventory. Do not create inventory items for the factory 
addition items. 

3 . MATERIAL REPORTING & DISBURSEMENTS 

1 . In workstation the user will see the substep displayed 
only for the cabinet in an assembly item. The substeps 
for the factory add-on items will be masked or will not 
be displayed. 

2. In BULK Reporting screens, the user will see the 
substep displayed only for the cabinet in an assembly 
item. The substeps for the factory add-on items will be 
masked or will not be displayed. 

3. This same process should be followed when a user 
completes on the Bulk reporting screens at a Job, Print 
and Step level. 

4. In Billing and Reporting the contractor will see the 
substep displayed for only the cabinet only in an 
assembly item. This is mainly because only the cabinet 
placement should generate CWI's. The substeps for the 
factory add-on items will be masked or will not be 
displayed because they do not have CWI's associated. 

5. When the user completes the substep that contains the 
cabinet, a material usage record is created and sent to 
materials for disbursement from the inventory. If that 
cabinet is part of an assembly, the materials 
disbursement process will auto-disburse the substeps 
containing the factory add-on items in that assembly by 
changing the substep material status to "D" and 
changing the substep status to "CO". 

6. The auto-disbursing process will not attempt to delete 
the factory add-on items from the inventory. 
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Performance Requirements: 

(list any performance 1 . There should be no noticeable affect on performance, 

requirements associated with 
this change) 



Dependencies: 

(list any defects or features that 1 . 
this enhancement is dependent 
on or that will be dependent on 
this feature) 



NONE 



Benefits: 

(provide benefits in dollars, 
reduced headcount, time 
savings, etc. for doing this 
work) 



1. Can handle the encoding, ordering, receipting, inventorying, 
reporting and disbursing of assembly items. 



Affected Components: 



(Check) 
Yes 



(Check) 
No 



RTOC Instructions 
HELP 
User Guides 
Testing 

Infra-structure 
Management Reports 
Database 



x 
x 

X 
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Interfaces: 

(list any legacy or new 
interface systems impacted by 
this change) 



1 . The DCPR report in the Management Reports Module will 
display all cabinets and all add-on information. This is already in effect 
with the existing report. 



Work- around: 

(is there a temporary work 
around?) 

(describe work around in 
detail) 



(Check) 
Yes 



(Check) 
No 

X 



There are work-arounds for part of this process, but it leaves "holes" in 
other areas of the application. For example, 

• M&Ps could be written to handle most of the jobentry edits, but 

if cable is ever encoded with an assembly code, that cable 
would be shipped to the vendor. 

• M&Ps could be written to instruct the user to order assembly 

items from the "Show Needed Requirements" window, but if 
they don't we may not order all of the items in the assembly 
since we cannot guarantee that all of the items would receive 
the same order date. 

• Since we inventory add-on items in a non-XPIDed assembly and 

don't inventory add-on items in a XPEDed assembly, reporting 
doesn't know how to "complete" the substeps. They could 
report zero quantity on those add-ons in the XPEDed assembly, 
but how would the user know the difference between an 
XPEDed assembly and a non-XPIDed assembly. 
• There is no work-around in the receipting process for XPIDed 

assembly items that have XPIDed add-ons. The user would not be able 

to receipt the cabinet if it wasn't the first item on the order. 



Risks: 

(list factors that impact, 1 . If this change is not done then the potential exists for some 

positive/negative, not doing items in an assembly to be missed in the ordering process. Other items 
this change) could be reported incorrectly. The user could order items in an 

assembly like cable and other non-assembly type items. This will lead 
to unnecessary expense to reconcile these types of situations. 
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Business Rules: 

(list any business rules or 1 . See changes above, 

constraints that should apply.) 

Document Changes: 

(list affected documents 1 . Help and User Guides 

requiring change) 



Acceptance Criteria/Test 
Scenario: 



(list test scenarios required to 
test change prior to user 
acceptance, this can be updated 
after the detailed design is 
complemented.) REQUIRED 



1 . Attempt to input into the jobentry screens a substep containing 
a description from the material item table category of Circuit_Eqpt and 
a sub-category of C ABINET- ADD-F AC . Do not enter an assembly 
code. Result should be an error message saying you need an assembly 
code with this material item. 

2. Add the assembly code above and try to save and close. Result 
- should get error message saying that a cabinet must have the same 
assembly code on the same step. Enter the cabinet from either of the 
sub-categories of "CABINET-HW" or "CABINET-HW&PI" under the 
category of CIRCUIT-EQPT on a different step with the same assembly 
code, (try each cabinet) Result - should get same error message. 

3. Enter a cabinet from some other Category and sub-category 
with the same assembly code on the same step and the result should be 
the same error message. 

4. Enter the cabinet from both of the sub-categories of 
"CABINET-HW" or " C ABINET-H W&PI" under the category of 
CIRCUIT-EQPT on the same step with the same assembly code. 
Result -should get error message saying that only one cabinet is 
allowed in an assembly item. 

5. Remove one of the cabinets and the system should accept the 
entry 

6. Encode a substep for a material description having an assembly 
indicator = "N" (i.e., cable) and enter an assembly code. Result - should 
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get error message saying that an assembly code is not allowed on this 
material item. 

7. Encode a substep for a cabinet having a subcategory of 
"CABINET-HW" or "CABINET-HW&PI with an assembly code but 
don't encode a factory-added substep on the step. Save the substep. 
Result - should get an error message stating that factory add-on material 
is missing from the assembly. 

8. Try to enter a non-alphanumeric character as the assembly 
code. Result - should not be able to produce the keystroke. 

9. Verify that after configuration that the substeps for the 
assembly item are in different activities. 

10. Verify that all of the material on the assembly item has the 
same order date when being ordered. This date should be 

based on the shipping interval of the cabinet 

1 1 . Verify that the XPIDed item is always the first item listed 
on the order. 

12. Try to add a factory add-on substep to an assembly after the 
cabinet has been ordered. Result - should get an error message which 
states that the substep cannot be added because the cabinet in that 
assembly has already been ordered. 

13. Verify that only the cabinet can be receipted on an assembly 
item. Receipt the cabinet on an assembly item. Verify that all of the 
other items in the assembly item are auto-receipted and that only the 
cabinet is placed in the inventory. 

14. Go to workstation and build a work report. Report the 
substep containing a cabinet that is part of an assembly item. 

15. Verify that the substeps in the assembly item that don't 
contain the cabinet are not seen or that they are grayed out 

on the screen. Verify that all other substeps containing that 
are part of the assembly are completed. 

16. Verify that a material is created for the cabinet only. 
Verify that only the cabinet is removed from the inventory. 
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17. Go to Bulk reporting screens and complete a substep containing 
the cabinet of an assembly item. Verify that the substeps in the 
assembly item that don't contain the cabinet are not seen or that they are 
grayed out on the screen 

1 8. Verify that all other substeps containing material that are part of 
the assembly item are auto-completed. 

1 9. Verify that a material usage is created for the cabinet only. 
Verify that only the cabinet is removed from the inventory. 

20. Repeat this process in Bulk Reporting at the Job, Print and Step 
level. 

21 . Go to Billing and Reporting and complete a substep containing 
the cabinet of an assembly item. Verify that the substeps in the 
assembly item that don't contain the cabinet are not seen. 

22. Verify that all other substeps containing material that are part of 
the assembly item are auto-completed. 

23. Verify that a material usage is created for the cabinet only. 
Verify that only the cabinet is removed from the inventory. 

• Include test cases for XPIDed and non-XPIDed assembly items. 

• Include test cases for an XPIDed add-on item with an XPIDed 
cabinet and an XPIDed add-on item with a non-XPIDed cabinet. 

Attachments: 

(copies of screens, reports, etc. 1. NONE 

before and after proposed 

change - only identify if the 

customer requires the screen or 

something on the screen to 

look a certain way) 

Signatures of Agreement: 

(add additional rows if necessary) 
BAE: 

Lead Analyst: 
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BAE Functional Requirement Document 



Table # 6372 

BAE Start Date: 06/18/1997 
BAE Comp. Date: 06/24/1997 
BAE Hours: 6 

CMVC Component Name: Job Entry - EWO 

Associated Defect/Feature 6372 
No.: 

Target Release: Target Release Date: 

(give target release this needs to 2.1 (give target release date for this 9/97 

be in) enhancement) 

Priority: 

(provide priority from 'feature priority' list - production_hi 
production ^ through deferredlow 

Revision No.: 
Reason for Revision: 

Subject: 

(brief description of change) 1 . Add code behind the CST/MPT number currently 

entered on the Job Information screen to route the work the 
proper resource. 



BAE Name: Gail Deaton 
BAE Tele. No.: 977-3615 
LA Assigned: 
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<L 



Introduction: 

(description of what system currently 
does, what needs to be changed, and 
why) 



Currently the CST/MPT number is a required field on 
the Job Information screen, but this information is not 
used by the system. Code needs to be built to use the 
CST/MPT number in configuration to determine which 
team to assign work to. This is required because 
currently there are instances of a MPT and a CST team 
being assigned to the same wire center. The system will 
assign the work to the resource that it finds first The 
user needs the ability to choose. 



Solution: 

(describe what the system will or 
should do and any general constraints 
or conditions that limit the solution) 



1 . The configuration editor should look for a CST/MPT 
number in resource assignment when configuring the job. If a 
match is found, then assign the work to the resource associated 
with the CST/MPT # entered. 



Change(s): 

(detailed description of change) - [add 
additional rows if multiple changes] 



EMPLOYEE EDITOR - add a field on the resource line 
to assign a CST/MPT# This field should be optional. 
This field should be 2 characters. This field should be 
effective on the day it is input No effective date is 
required! 

JOB INFORMATION SCREEN - Change the 
CST/MPT# field to optional. 

CONFIGURATION - On a substep save, the existing 
configuration code assigns a resource by selecting the 
first resource it comes to that can perform the substep 
work type in the wire center 

If a CST/MPT# is populated. Change the 
configuration process to read if a CST/MPT# is 
populated, if this field is populated, find a 
match with the resource that can perform the 
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substep work type. Assign the work to this 
resource. This must be done for every substep. 
If the CST/MPT# is blank. Assign a resource to 
the substep as in the existing code. 
If the CST/MPT# is populated but no matches 
are found in the resources that can perform the 
work. Assign a resource to the substep as in the 
existing code. 
4. If a CST/MPT# is changed or deleted after 

configuration. The entire job must be reconfigured. 
Enter a message on the save, when this field is changed 
after a initial configuration. EMU should read. You are 
possibly changing the assignment of resources for this 
job. Do you want to continue and reconfigure the job. 
YES or NO 



Performance Requirements: 

(list any performance requirements 1 Performance should not be affected by this feature, 
associated with this change) 

Dependencies: 

(list any defects or features that this 1 . 
enhancement is dependent on) 



Benefits: 

(Provide benefits in dollars, reduced 1 . The current code does not allow the assignment of a 
headcount, time saving, etc, for doing CST or MPT team. Changes to direct the work to the correct 
this work) resource are currently being performed after configuration in 

the scheduling module. This function will eliminate the manual 
effort associated with moving this work to the proper resource. 
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Affected Components: 



(Check) (Check) 
Yes No 



RTOC Instructions 
HELP 

User Guides 

Testing x 
Infra-structure 

Management Reports x 
Database 

Interfaces: 

(list any legacy or new 1 . 
interface systems 
impacted by this 
change) 



Work-around: 

(is there a temporary work 
around?) 

(describe work around in 
detail) 



(Check) 
Yes 

X 



(Check) 
No 



1 . The work is moved to the proper resource in the scheduling module 
manually. 



Risks: 

(list factors, that impact, 
positive/negative, not doing 
this change) 



1 . Confusion of the users by thinking that the input of the 
CST/MPT # will drive the work to the proper resource. The confusion 
of the work being assigned to the wrong resource and the manual effort 
to correct the problem. 



Business Rules: 

(list any business rules that 1 . 
should apply) 
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Documentation Changes: 

(list affected documents 
requiring change) 

Acceptance Criteria/Test 
Scenario: 

(list test scenarios required to 
test change prior to user 
acceptance) REQUIRED 



1. 

4 



1 . Assign CST/MPT # "1" to a existing resource in test. Assign 
CST/MPT # "51" to a different resource. 

• Verify that the field is optional. 

• Verify that the changes in this field are effective 
immediately. 

2. In configuration tables - assign the same work to each of 
the two resources for a wire center. 

3 . In Job Entry EWO enter a new job (in the wire center that was 
changed in configuration) and specify CST/MPT # 

" 1 " on the job information screen. 

• Enter substeps on the job and save. 

• Configure the job . 

• Print the 206 Report out of Workstation Presurvey to verify 
the assignment of the correct resource. 

4. In Job Entry EWO enter a new job and 

specify CST/MPT # "51" on the job information screen. 

• Enter substeps on the job and save. 

• Configure the job. 

• Print the 206 Report out of Workstation Presurvey to verify 
the assignment of the correct resource. 

5 . In Job Entry EWO enter a new job in a and specify 
CST/MPT # "blank" on the job information screen. 

• Enter substeps on the job and save. 

• Configure the j ob . 

• Print the 206 Report out of Workstation Presurvey to verify 
the assignment of one of the resources. (System should 
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have selected the first it came to.) 

6. In Job Entry EWO enter a new job in a and specify 
CST/MPT # "99" on the job information screen. 

• Enter substeps on the job and 

save. « Configure the job. 

• Print the 206 Report out of Workstation Presurvey to verify 
the assignment of one of the resources. (System should 
have selected the first it came to.) 

7. In Job Entry EWO enter a new job in a and specify 
CST/MPT # "1" on the job information screen. 

• Enter substeps on the job and save. 

• Configure the job. 

• Print the 206 Report out of Workstation Presurvey to verify 
the assignment of the resource associated with CST/MPT # 
1. 

• Access the Job Information screen again. Change the 
CST/MPT#to"51 "and save. 

• You should get EMU "You are possibly changing the 
assignment of resources for this job. Do you want to 
continue and reconfigure the job? YES or NO 

• Select YES 

• Print the 206 Report out of Workstation Presurvey to verify 
the assignment of the resource associated with CST/MPT # 
51. 

8. In Job Entry EWO enter a new job in a and specify 
CST/MPT # "1" on the job information screen. 

• Enter substeps on the job and save. 

• Configure the job. 

• Print the 206 Report out of Workstation Presurvey to 
verify the assignment of the resource associated with 
CST/MPT # 1. 

• Access the Job Information screen again. Change the 
CST/MPT # to "51 "and save. 
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• You should get EMU "You are possibly changing the 
assignment of resources for this job. Do you want to continue and 
reconfigure the j ob? YES or NO 

• Select NO 

• Print the 206 Report out of Workstation Presurvey to verify 
the assignment of the resource associated with CST/MPT # 1 . 

Attachments: 

(copies of screens, reports, etc. 1 . 
before and after proposed 
change) 

Signatures of Agreement: 

(add additional rows if necessary) 
BAE: 

Lead Analyst: 



Exh. 2 - Page 467 



BAE Functional Requirement Document 



Table # 6403 

BAE Start Date: 05/15/1997 BAE Name: Gail Deaton 

BAE Comp. Date: 05/15/1997 BAE Tele. No.: 977-3615 

BAE Hours: 2 LA Assigned: 

CMVC Component Name: CS - Job Entry Editor 

Associated Defect/Feature 
No.: 

Target Release: Target Release Date: 

(give target release this needs to phase_3 .0 (give target release date for this 09/0 1/1997 

be in) enhancement) 

Priority: 

(provide priority from 'feature priority' list - med 
productionjii through deferred low 

Revision No.: 
Reason for Revision: 

Subject: 

(brief description of change) 1 . Develop a presentation for the CI and the CWI tables 
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Introduction: 

(description of what system currently 
does, what needs to be changed, and 
why) 



1 . OSPCM currently does not have a presentation for the 
CI and the CWI table. Core Staff must access ISQL forms to 
enter updates to these tables. Adding these forms (with edits) to 
OSPCM will reduce the difficulty of these table updates. In 
addition, the user currently does not have access to view these 
tables. By having this forms in CS -Job Entry Editor, the user 
can view these tables. 



Solution: 

(describe what the system will or 
should do and any general constraints 
or conditions that limit the solution) 



Develop a presentation for the CI and the CWI tables. 
The fields that are available on the current ISQL forms 
should be used. 

Search will be focused on the individual CI code or the 
CWI code. 



Change(s): 

(detailed description of change) - [add 
additional rows if multiple changes} 



1 . Add the CI and the CWI table forms to CS - Job Entry 
Editor. 



Performance Requirements : 

(list any performance requirements 1 . Performance should not be affected, 
associated with this change) 

Dependencies: 

(list any defects or features that this 1 . 
enhancement is dependent on) 



Benefits: 

(Provide benefits in dollars, reduced 1 . Benefit from this feature is ease in table updates and 
headcount, time saving, etc, for doing the accuracy of data, 
this work) 
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Affected Components: (Check) (Check) 

Yes No 



RTOC Instructions 

HELP x 

User Guides x 

Testing x 

Infra-structure 

Management Reports 

Database 



Interfaces: 

(list any legacy or new 1 . 
interface systems 
impacted by this 
change) 



(Check) (Check) 
Work-around: Yes No 

(is there a temporary work X 
around?) 

(describe work around in 1 . Leave form access in ISQL. 

detail) 



Risks: 

(list factors that impact, 1 . Accuracy of data and access for the user will be impacted, if 

positive/negative, not doing this feature is not done, 
this change) 



Business Rules: 

(list any business rules that 1 . 
should apply) 
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Documentation Changes: 

(list affected documents 1 . 

requiring change) 

Acceptance Criteria/Test Scenario: 

(list test scenarios required to 1 . 
test change prior to user 
acceptance) REQUIRED 2. 

3. 

4. 

Attachments: 

(copies of screens, reports, etc. 1 . 
before and after proposed 
change) 

Signatures of Agreement: 

(add additional rows if necessary) 
BAE: 

Lead Analyst: 



Compare the OSPCM CI and CWI presentation to the ISQL 

presentation and verify that all fields are captured. 

Make changes in the fields for a CI and save. Make sure the 

changes are saved and applied to configuration 

Make changes in the fields for a CWI and save. Make sure the 

changes are saved and applied to configuration. 

Log on as a read-only user type. Make sure this user type does 

not have update capability. 
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